Triage Bugs Like a Doctor: A 5-Step Severity System That Works

Why Bug Triage Is the Hardest Part of Bug Tracking

Let's be honest: bug tracking tools like Jira, Bugzilla, Linear are great at storing bugs. They give you fields for priority, severity, assignee, status. But the hardest part isn't the tool—it's the triage. That's the moment you decide which bugs get fixed now, which wait, and which get closed as 'won't fix.'

Most teams we've seen treat triage as a labeling exercise. They set severity to 'High' if the bug is annoying, 'Low' if it's not. Then they let the backlog grow until the noise drowns out the signal. That's not triage. Triage is a decision-making process that balances user impact, business cost, and engineering effort. It's the difference between a bug tracker that helps and one that just stores complaints.

In this article, we'll give you a concrete 5-step triage system that you can implement this week. It's based on practices we've observed in high-performing software teams, and it doesn't require fancy tools—just discipline and a shared framework.

Step 1: Use a Consistent Severity Scale

Before you can triage, you need a common language. The classic scale is Severity 1 (S1) to Severity 4 (S4), but many teams misuse it. We recommend a definition that ties severity to user impact and workaround availability:

• S1 – Critical: Complete loss of service, data corruption, or security breach. No workaround. Example: a payment gateway that fails on all transactions.
• S2 – High: Major feature broken for many users, but a workaround exists. Example: login fails on the mobile app, but users can use the web version.
• S3 – Medium: A feature is partially broken or affects a small user segment. Example: a typo in an email template, or a dropdown that doesn't show all options.
• S4 – Low: Cosmetic or edge-case issues. Example: a misaligned button on a rarely visited page.

Adopt this scale as a team, and make sure everyone uses the same definitions. Post them in your bug tracker's description or as a comment template. If your team already has a scale, audit it for consistency—we often see S2 used for 'annoying but rare' bugs, which inflates priority.

Step 2: Score User Impact with a Simple Formula

Severity alone isn't enough. A bug that affects one enterprise customer with a workaround might be S3, but if that customer pays $100k/year, it might be urgent. That's why we recommend a triage score that combines frequency, impact, and detection ease. Here's a formula we've seen work in practice:

Triage Score = (User Impact × 2) + (Frequency × 1.5) + (Detection Difficulty × 0.5)

Where each factor is scored 1–5:

• User Impact: How much does it hurt the user? 1 = minor annoyance, 5 = blocks a core task.
• Frequency: How often does it occur? 1 = once a month, 5 = every session.
• Detection Difficulty: How hard is it to find? 1 = obvious, 5 = only shows under rare conditions.

The higher the score, the higher the priority. For example, a bug that blocks checkout (Impact 5, Frequency 4, Detection 2) scores (5×2)+(4×1.5)+(2×0.5)=10+6+1=17. A cosmetic typo (Impact 1, Frequency 3, Detection 1) scores 2+4.5+0.5=7. This removes guesswork and makes triage defensible.

Step 3: The 5 Whys for Recurring Bugs

When a bug keeps coming back, triage shouldn't just re-prioritize it—it should dig into the root cause. The 5 Whys is a simple technique: ask 'why' five times to get to the underlying process failure. We've seen a team reduce recurring bugs by 40% after applying this to their top 10 issues in one quarter.

Example: Bug #452: Users report duplicate orders after double-clicking 'Place Order.'

1. Why? The button isn't disabled during processing.
2. Why? The front-end doesn't have a loading state.
3. Why? The developer didn't know about the existing loading component.
4. Why? The component wasn't documented in the style guide.
5. Why? The style guide is outdated and not maintained.

Now you're not just fixing the button—you're fixing the documentation process. In triage, mark such bugs as 'process' and assign a follow-up task to update the guide. This turns bug tracking into a proactive tool.

Step 4: The 24-Hour Rule for New Bugs

Many teams let bugs sit in 'New' for days, which makes triage a chore. We recommend a 24-hour rule: any new bug must be triaged within 24 hours of being filed. That doesn't mean it gets fixed in 24 hours—just that it gets a severity, a triage score, and a decision (fix now, fix later, or won't fix).

This prevents the backlog from becoming a black hole. In our experience, teams that adopt a 24-hour rule see a 50% reduction in 'stale' bugs (bugs untouched for 30+ days). It also forces the product manager to stay engaged. You can automate this with a bug tracker rule: if a bug is unassigned for 24 hours, send a reminder to the on-call triage owner.

Step 5: The Weekly Triage Meeting (with a Timebox)

Once you have a system, you need a rhythm. We recommend a 30-minute weekly triage meeting, not a daily one. In that meeting, review only new bugs and those with a triage score above a threshold (say, 12). Go through them quickly, assign priorities, and make decisions. Don't fix bugs during the meeting—that's a separate activity.

One trick: use the 'swimlane' method. Divide the board into three columns: 'Fix this sprint,' 'Fix later,' and 'Won't fix.' As you triage, drag each bug into a column. This gives visual clarity and prevents endless discussion. We've seen a team cut its triage meeting from 60 minutes to 20 by using this technique.

Tools and Automation for Triage

While the process is manual, you can automate parts of it. Jira and Linear allow you to create custom fields for the triage score and to set up rules that auto-assign or notify. For example, you can create a 'Triage Score' field and use a formula to calculate it automatically from other fields. Or use an integration like Zapier to send a Slack message when a new bug arrives.

But beware of over-automation. A bug tracker can't judge user impact for you. We've seen teams rely on AI to triage bugs, but it often misclassifies severity because it lacks context. Use automation for reminders and calculations, not for judgment.

What to Do with 'Won't Fix' Bugs

Every triage system must allow for 'won't fix.' This is not a failure—it's a decision. When you close a bug as 'won't fix,' document why: 'Low impact, high effort,' 'Deprecated feature,' or 'By design.' This prevents future arguments and gives a paper trail.

In our triage framework, any bug with a triage score below 8 and a fix effort above 5 story points is a candidate for 'won't fix.' But always double-check with a customer-facing team member. Sometimes a 'small' bug affects a key customer.

Case Study: How a SaaS Team Reduced Bug Backlog by 60%

To make this concrete, here's an example from a real SaaS company we worked with (name anonymized). They had a backlog of 1,200 bugs. After implementing the 5-step system—severity scale, triage score, 5 Whys for recurring bugs, 24-hour rule, and weekly triage—they reduced the backlog to 480 in three months. That's a 60% reduction.

They also saw a 30% drop in customer-reported issues because they fixed the recurring bugs that caused the most complaints. Their bug tracker became a source of truth for product decisions, not just a list of problems.

Final Takeaway

Bug triage is a skill, not a chore. By using a consistent severity scale, a scoring formula, and a disciplined meeting rhythm, you can make your bug tracker a strategic asset. Start small: adopt the severity scale this week, and add the score next week. Measure your backlog size before and after. You'll see the difference.