Severity vs Priority: How to Run a Bug Triage That Works in 2026

The Quick Answer

Severity and priority are two different judgements about the same defect, made by two different people for two different purposes. Teams that merge them into one field end up arguing about numbers instead of making decisions.

Severity describes the technical impact of the defect on the system. How badly does it break things? It is assessed by whoever found and reproduced it, and it does not change based on business context.

Priority describes the urgency of fixing it. When should this be worked on, relative to everything else? It is a business and scheduling decision, and it can change without the defect changing at all.

In one line: Severity is a property of the bug. Priority is a property of the plan.

This article covers how to define each scale so it produces consistent judgements, the four severity-priority combinations that confuse teams, how to attach service levels to priority, and how to run a triage meeting that ends in decisions rather than a longer backlog. For how to write the defect report itself, see our bug report template.

What Severity Means

Severity answers a question about the system: what is the consequence of this defect when it occurs? It is assessed against the behaviour of the software, not against the calendar or the roadmap.

Three factors drive a severity assessment. The first is functional loss - whether the affected capability is unavailable, degraded, or merely imperfect. The second is data integrity: a defect that corrupts, loses, or exposes data is severe regardless of how rarely it fires, because the damage persists after the bug is fixed. The third is whether a workaround exists - a complete blockage with no way around it is more severe than the same failure with a documented alternative path.

What severity is not: Severity is not affected by how many customers hit the defect, how visible it is to a specific account, or whether a release is due next week. Those are all real considerations, and they all belong to priority. Keeping them out of severity is what makes severity comparable across defects.

Who Sets It

The person who reproduced the defect sets severity, because it requires knowing what actually happens - which data is affected, whether the failure is recoverable, whether a workaround exists. It is a testable, evidence-based judgement, which is why it should be relatively stable once set.

What Priority Means

Priority answers a scheduling question: relative to everything else waiting, when should this be fixed? It is a business judgement and it is legitimately volatile - the same defect can be low priority in one sprint and top of the list in the next because circumstances changed.

Factors that properly drive priority:

• Number of users affected - a minor annoyance hitting every user can outrank a serious failure in a rarely-used path
• Who is affected - a defect blocking a major customer's evaluation, or a whole segment
• Revenue and contractual exposure - lost sales, SLA breaches, penalties
• Regulatory and legal deadlines - a compliance requirement with a date attached
• Reputational visibility - a defect on a public page or in a launch feature
• Timing - whether a release is imminent and whether the fix is safe to make now
• Cost and risk of the fix - a one-line change and a three-week refactor with the same severity do not schedule the same way
• Dependencies - whether other work is blocked until this is resolved

Who Sets It

Priority belongs to the product owner or whoever holds the roadmap, informed by the severity assessment. QA supplies the evidence; the business makes the call. This split is what prevents the two most common dysfunctions: testers setting priorities they lack the business context for, and product owners overriding severity assessments they have not reproduced.

Severity vs Priority Side by Side

The Four Combinations

The reason to keep the fields separate is that all four combinations occur, and each implies a different response. Teams with a single field cannot express any of them.

The two middle rows are the whole argument. A single combined field forces you to misrepresent one of them: the legacy crash gets logged as critical and then ignored, which teaches everyone that critical does not mean critical, or the pricing page typo gets logged as trivial and misses the launch. Two fields let both be described accurately and handled correctly.

Defining a Severity Scale

Four levels is enough. Definitions must be concrete enough that two testers assessing the same defect independently reach the same answer - that is the only real test of a severity scale.

Two rules that keep the scale honest: Anything involving data loss, data corruption, or unauthorised data exposure is S1 regardless of how narrow the trigger is, because the harm outlives the fix. And the availability of a workaround lowers severity by one level at most - it does not turn a broken feature into a cosmetic issue.

Defining a Priority Scale With Service Levels

A priority scale is only meaningful if each level carries a commitment. Without target times, priority is a label; with them, it is a plan.

Set the targets to numbers your team can actually meet. A P2 target that is missed routinely trains everyone to ignore the field, at which point the scale has stopped functioning. It is better to define P3 as "within two cycles" and hit it than to define it as "next sprint" and miss it every time.

P4 deserves an explicit policy. A backlog of low-priority defects that only grows is a source of noise that makes triage slower every week. Either commit to reviewing it on a cadence and closing what will realistically never be fixed, or acknowledge that P4 means closed-with-a-record. Keeping defects and their status linked to the test cases that found them - through issue tracker integration - at least ensures a closed low-priority defect resurfaces if the same test fails again later.

Running a Triage Meeting

Triage is where severity meets priority and defects get assigned. Done well it takes twenty minutes; done badly it becomes an hour-long status meeting that decides nothing.

Who Attends

Four roles, kept small deliberately: a product owner to set priority, a QA representative to explain impact and reproduction, an engineering lead to estimate effort and risk, and - for a live product - someone from support who knows what customers are actually reporting. More attendees than that turns decisions into discussions.

The Agenda

• 1. New defects since the last session. Confirm severity, assign priority, assign an owner. Two minutes each maximum.
• 2. Anything with a missing or disputed severity. Resolve it with evidence, not opinion - if nobody can say what the impact is, the report is incomplete and goes back.
• 3. Overdue items against their service level. Either re-prioritise honestly or escalate; do not silently let targets lapse.
• 4. Anything whose context has changed. A defect can become urgent because a customer escalated or a release moved - this is the legitimate place to change priority.
• 5. Ageing low-priority items. Close what will not be fixed. This is the step everyone skips and the reason triage gets slower over time.

Rules That Keep It Short

Every defect leaves the meeting with a severity, a priority, and a named owner - no "we will look into it." Nothing gets triaged without evidence: a report with no reproduction steps and no telemetry goes back for information. A defect that resists reproduction but has evidence behind it - an error rate, a customer report, a crash log - does get triaged, with an owner assigned to investigate rather than to fix. Debate about a fix belongs outside the meeting; triage decides what and when, not how. And if the same defect is discussed in three consecutive sessions, that is a signal to either commit to it or close it.

Frequency should match the flow. A team producing a handful of defects a week needs one session per week; a team in the final phase of a release may need a short daily one. What matters more than cadence is that the session ends with every new defect assigned.

Common Mistakes

• One combined field. The most common and most costly mistake - it makes the two useful combinations inexpressible and guarantees that "critical" gets devalued.
• Testers setting priority. QA has the impact evidence but not the commercial context. Assigning priority from the tester's seat produces a queue nobody in the business agrees with.
• Product owners rewriting severity. Lowering severity to avoid a release gate does not make the defect less broken; it makes your defect data useless for trend analysis.
• Everything is P1. If more than a small fraction of defects are top priority, the field carries no information and the real ordering is being decided informally elsewhere.
• No definitions written down. Without concrete definitions, severity drifts by tester and priority drifts by whoever is loudest that week.
• Service levels with no consequence. Targets that are missed without comment stop influencing behaviour within a month.
• Never closing the tail. An unbounded low-priority backlog slows every future triage and hides the items that matter.
• Skipping the workaround question. Whether a workaround exists changes both severity and how urgently the fix is needed, and it is the field most often left blank.

Conclusion

Severity and priority are separate because they answer separate questions and are owned by separate people. Severity is a technical assessment of how badly the software is broken, made by whoever reproduced it, stable once set. Priority is a business decision about when it gets fixed, made by whoever owns the roadmap, and legitimately subject to change.

Keeping them apart is what makes a defect queue trustworthy. It lets a team say "this is genuinely broken and we are not fixing it this quarter" without corrupting the data, and "this is a one-character change and it ships today" without pretending it was a critical system failure. Add concrete definitions for each level, a service level attached to each priority, and a short triage session that ends with every defect owned, and the process runs on decisions instead of argument.

The one prerequisite is that defects and the tests that found them stay connected. QA Sphere links defects raised during a test run back to the test case that caught them and out to your tracker through issue tracker integration, so triage works from evidence and reporting shows where defects concentrate. See pricing or book a demo.