Severity and priority are the two most-confused fields in any bug tracker. Many teams use them interchangeably, which leads to angry triage meetings and bugs that get fixed in the wrong order. The distinction is simple, important, and worth getting precise about.
The clean definitions
Severity describes how bad the bug is when it happens. It is a property of the defect itself — independent of how often it occurs or who hits it.
Priority describes how soon the bug needs to be fixed. It is a business decision that combines severity, frequency, business impact, and the cost of the fix.
A bug can be high severity and low priority, or low severity and high priority. A useful matrix:
Severity × priority matrix
| Low priority | High priority | |
|---|---|---|
| High severity | Edge case data loss — rare but real | Login broken — fix now |
| Low severity | Tiny admin polish — backlog | Misaligned logo on homepage |
| High priority | Low priority | |
|---|---|---|
| High severity | Critical: fix now (e.g., login broken for all users) | Edge case: real damage but rare (e.g., data corruption only when timezone is Antarctica) |
| Low severity | Visible cosmetic: easily noticed by many (e.g., logo misaligned on the homepage) | Polish: trivial and rare (e.g., extra space in an internal admin tool) |
Why the distinction matters
Imagine two bugs landing on a Friday afternoon:
- Bug A. When a user makes a single specific edit to their address, their account becomes permanently unloggable. There is no workaround, but only 0.001% of users hit it per day.
- Bug B. The header logo is 4 pixels off-centre on the marketing site, visible to everyone.
By severity: A is catastrophic (user locked out forever), B is trivial (4 pixels). By priority: A is medium (rare), B is high (the marketing team is shipping a campaign on Monday).
Without the distinction, you cannot have an honest conversation about which to fix first. Bug A should be fixed urgently because the affected users are completely blocked, but it might be deferred to next sprint because the rate is so low. Bug B should ship today because it embarrasses the brand. Both decisions are defensible — and only possible because the two fields exist independently.
Common severity scales
Most teams use four or five levels. A typical scale:
- Blocker / Critical. The system is unusable. Production is down. No reasonable workaround.
- High / Major. A core feature is broken, but a workaround exists or other features still work.
- Medium / Minor. A non-core feature is broken, or a core feature has a degraded experience.
- Low / Trivial. Cosmetic, edge case, polish.
Some scales add a fifth level for "data loss / security" issues that need their own handling regardless of frequency.
Common priority scales
Often P0 to P3 or P1 to P5:
- P0. Drop everything. Fix today. Wakes people up.
- P1. Fix this sprint. Top of the next standup.
- P2. Fix next sprint or two.
- P3. Backlog. Will be done eventually, or maybe not.
The label matters less than the agreement. Every team needs a shared answer to "what does P1 mean here?" — concrete enough that two people in different rooms would assign the same priority to the same bug.
Frequency and impact: the missing dimensions
In practice, both severity and priority are often computed implicitly from two underlying dimensions:
- Severity-of-impact — how bad is it when it happens?
- Frequency — how often does it happen?
A bug that breaks the experience for 10% of users every day is more important than one that destroys data for 1 user per year, even if the latter has worse per-incident damage. Smart triage holds both numbers in mind.
A useful triage habit: for any P0/P1 bug, write down the rough numbers. "Severity: high (data loss). Frequency: ~50 reports/week. Estimated affected users/day: 200." Numbers eliminate arguments — the bug's importance is no longer a matter of opinion.
Severity is set by QA; priority is set by triage
A clean division of labour:
- QA engineer sets initial severity. They saw the bug, they know how bad it is. Severity is a technical assessment.
- Triage team (product manager + tech lead + QA lead) sets priority. They weigh severity against business context — release timing, customer commitments, fix cost, alternate workarounds.
Keeping the two fields under different owners helps prevent the failure mode where every reporter marks their own bug as "P0" and the queue becomes meaningless.
What you should walk away with
Severity = how bad. Priority = how urgent. They are independent. A clear separation saves triage meetings from becoming bargaining sessions and gives engineering a defensible queue. The next chapter turns from bug reports to the artefacts QA produces in larger volumes than any other: test cases.