Severity measures a bug’s impact — how bad it is when it happens. Priority measures its order — when you’ll deal with it relative to everything else. They’re independent axes: a bug can be high on one and low on the other. Severity is mostly observed by whoever reports the bug; priority is decided in triage, against the whole queue.
The two get conflated constantly, and the cost of conflating them is real: either everything becomes “urgent,” or genuine fires sit behind cosmetic noise. Keeping them as two separate fields is what keeps triage honest.
TL;DR
- Severity = impact (a property of the bug). Priority = order (a decision about the queue).
- They usually correlate, but the decisions that matter happen where they diverge.
- Severity is suggested by the reporter; priority is owned by whoever triages.
- A typo on your pricing page is low severity, high priority. An admin-only crash is high severity, low priority.
What’s the difference between severity and priority?
Severity describes how much damage the bug does when it occurs — independent of how often it happens or what else is on your plate. Priority describes when you’ll fix it relative to every other piece of work competing for the same time. One is a measurement; the other is a scheduling decision.
The clean test: severity is about the bug, priority is about the queue. You can assess severity by looking at the bug alone — what breaks, for whom, how recoverably. You cannot assess priority by looking at the bug alone, because priority only means anything relative to everything else you could be doing instead.
Is the severity–priority split official, or just a convention?
It’s codified, not a matter of taste. The software-testing profession’s reference vocabulary, the ISTQB glossary, defines the two terms separately and precisely — severity as:
“The degree of impact that a defect has on the development or operation of a component or system.”
and priority as:
“The level of (business) importance assigned to an item, e.g., defect.”
Read back to back, the split is unmistakable: severity speaks to impact on the system, priority to business importance — a technical reading and a business one, which is also why they tend to be owned by different people. IEEE Std 1044-2009, the standard classification for software anomalies, likewise records severity and priority as two distinct attributes of a defect, not one. So a tracker that collapses them into a single field isn’t simplifying — it’s diverging from the vocabulary the rest of the industry already shares.
The same line runs straight through incident response, where it’s often put more sharply than in the QA literature. A formulation you’ll see again and again in incident-management writing captures it in a single breath:
Severity is an attribute of the incident; priority is a decision made by the responder.
That is, severity is a fact you read off the problem; priority is a judgment a person makes about the response. A SEV-1 can be pushed down to a low priority when a dozen other fires are burning and responders are scarce, and a mild issue hitting a strategic customer can be bumped up — the same decoupling we saw in the matrix above, in a different setting. The bug-tracking distinction and the incident SEV-level distinction are the same idea in different clothes: impact-versus-urgency is a general pattern for ranking any queue of problems, not a quirk of bug trackers. (Primers from incident-management vendors: incident.io, Atlassian, FireHydrant.)
Why do severity and priority get confused?
Because most of the time they move together, so it’s tempting to treat them as one slider. A bug that wipes out customer data is both maximally severe and obviously the next thing you fix. When severity and urgency agree, you never notice they’re two different things — one knob would do.
They come apart at the edges, and the edges are exactly where triage earns its keep. A wrong price on your marketing site doesn’t break anything technically (low severity) but it’s bleeding trust and sales every hour it’s live (high priority). A crash deep in an internal tool used twice a year is genuinely severe but can wait indefinitely. Collapse the two into one field and you lose the language to describe these — so they get mis-scheduled.
The severity–priority matrix
The four combinations map to four different responses. This is the whole concept in one table:
| High priority (do it soon) | Low priority (it can wait) | |
|---|---|---|
| High severity (big impact) | Checkout loses orders on large carts → fix now | Crash in a rarely-used internal admin tool → backlog it |
| Low severity (small impact) | Typo in the price on your pricing page → fix today (costing sales) | Misaligned icon on a settings screen → whenever |
The two diagonal cells are the ones people get wrong. The top-right (severe but rare) tempts you to drop everything for something almost no one hits. The bottom-left (trivial but visible/costly) is easy to dismiss as “just a typo” when it’s quietly doing commercial damage. Reading severity and priority as separate axes is what lets you tell those two apart.
How do you set severity?
Severity is the more objective of the two — you can assess it from the bug itself, which is why the person who reports the bug is well placed to propose it. Judge it on impact, roughly in this order:
- Data integrity — does it corrupt, lose, or expose data? This is the top of every severity scale.
- Scope of breakage — is the whole feature dead, or just degraded? Does it hit every user or one edge case?
- Workaround — can the user get unblocked another way, or are they fully stuck?
- Reversibility — can you undo the damage, or is it permanent?
Most teams bucket this into a handful of levels — Critical / Major / Minor / Trivial, or S1–S4. The exact labels don’t matter; consistency does. And note: severity is a property of the bug, so it shouldn’t drift as your roadmap changes. A data-loss bug is severe whether you fix it today or next quarter.
How do you set priority?
Priority is a judgment call, not a measurement, and it can only be made with the whole queue in view — which is why it belongs to whoever triages, not to the reporter. Severity is the biggest input, but it’s not the only one:
- Frequency — a mild bug a thousand users hit daily can outrank a severe one nobody triggers.
- Who’s affected — a paying enterprise account vs. a free trial vs. an internal user.
- Cost to fix — a one-line fix and a two-week rewrite compete differently for the same slot.
- Timing — a checkout bug the week of a launch is a different decision than the same bug in a quiet month.
- What else is in flight — priority is relative by definition; it shifts as the rest of the queue shifts.
Because of that last point, priority is mutable in a way severity isn’t. The same bug can be P2 today and P0 next week because the context around it changed, even though its severity never moved.
Who sets severity vs priority?
Split the responsibility along the same line as the definitions. The reporter or QA suggests severity — they witnessed the impact, so they’re closest to the truth of how bad it is. Whoever owns triage (a PM, a tech lead, an on-call engineer) sets priority — they’re the only one who can see this bug against everything else competing for the team’s time.
This is also good advice for the person filing the report: state severity honestly because you know the impact, and suggest a priority rather than declaring one — the final call isn’t yours to make from inside a single ticket. (More on that in how to write a bug report someone can act on.)
The one-field trap
Here’s the failure mode worth naming, because almost every overloaded backlog has it: a tracker with only one urgency knob. When reporters can’t record impact separately, they pour their fear of impact into the only field they have — so everything they file becomes “high.” Priority inflates until it’s meaningless, and the genuinely urgent work is indistinguishable from the loud work.
Two fields fix this by giving impact and order their own homes. The reporter records how bad it is; triage decides when it’s handled; nobody has to smuggle one signal through the other. That’s the practical reason the distinction is worth the small overhead of a second field — it’s not bureaucracy, it’s what stops your queue from collapsing into a single undifferentiated pile of “urgent.”
Frequently asked questions
Can a bug be high severity but low priority? Yes — that’s the most important case to understand. A severe crash in a feature almost nobody uses (say, an internal admin tool run twice a year) has major impact but can wait, because the cost of leaving it is low. High severity, low priority.
Can a bug be low severity but high priority? Also yes. A typo in the price on your pricing page breaks nothing technically, but it costs sales and credibility every hour it’s live, so you fix it today. Low severity, high priority.
Is severity or priority more important? Neither — they answer different questions. Severity tells you how bad; priority tells you when. You need both to schedule work sensibly. If forced to act on one, priority drives the schedule — but priority set without honest severity data is just guessing.
Who decides priority? Whoever owns triage — a PM, tech lead, or on-call engineer — because only they can weigh the bug against the rest of the queue. The reporter should suggest a priority, but the decision is a queue-level one, not a ticket-level one.
Should severity ever change? Rarely. Severity is a property of the bug, so it only changes if you learn the actual impact was different from your first assessment — not because your roadmap shifted. If a bug’s number is moving because of scheduling, that’s priority, not severity.
Are severity and priority different in Jira or other trackers? The concept is universal even where the field names differ. Most trackers expose them as two separate fields precisely because they’re two separate decisions; some teams rename them (impact/urgency) but the split is the same. The mistake — collapsing them into one — is also universal.
How Bugspot thinks about it
We keep severity and priority as distinct, structured fields in Bugspot (currently in public beta) for exactly the reason above: they’re two different decisions made by two different people at two different moments, and merging them quietly destroys information. It fits the broader bet — a fixed, sensible structure where the important distinctions are built in, rather than a pile of free-form fields every team has to reinvent.
You don’t need Bugspot to apply this, though. Wherever you track bugs, give impact and order their own fields, let the reporter speak to severity and triage own priority, and watch how much faster a consistent queue is to reason about. The distinction is small; the clarity it buys is not.