A support team can run a clean bug queue and still fix the wrong things first. Not because the reports are bad, but because two words that sound interchangeable get treated as one number. Severity and priority are different measurements, set by different people, for different reasons. Collapse them into a single field and you get a queue that is either technically ranked and commercially wrong, or commercially ranked and blind to what is actually on fire.
This guide is the reference version of that distinction. It defines the four bug severity levels and the four bug priority levels, shows how to assign each with worked examples, lays out the severity-priority matrix that combines them, and names the mistakes that quietly reorder the queue. If you want the surrounding workflow rather than the levels themselves, the bug triage process guide covers the sorting decision end to end.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Severity vs Priority: The One-Sentence Difference
Severity is how bad the bug is. Priority is how soon you fix it. That is the whole distinction, and everything else follows from it.
Severity is a property of the bug. It answers "how broken is this?" on technical and user-experience grounds, with no business context. A data-loss bug is high severity whether it hits one account or one thousand. Because it is a property of the bug, severity is relatively objective and it rarely changes after it is set.
Priority is a decision about the bug. It answers "what do we do next?" and it depends entirely on context that lives outside the code: how many customers are affected, how much revenue is at risk, which accounts are near renewal, and what else is in the queue. Because it is a decision, priority is subjective by design and it can change every week as the situation moves.
A bug has one severity but its priority can move every week. Treating those as the same number is how the wrong bug ends up at the top of the queue.
The Four Bug Severity Levels
Severity is an engineering or QA call, because judging how broken something is requires knowing how the system works. Four levels are enough for almost every team. Write the definitions down and keep them visible so severity becomes a lookup rather than a debate.
| Severity | Definition | Example |
|---|---|---|
| Critical | The product is down, or data is lost or corrupted, with no workaround. | Login is broken for all users, or a save silently drops customer records. |
| High | A core feature is broken for many users, and any workaround is painful or non-obvious. | Checkout fails for one payment method, or exports produce a corrupt file. |
| Medium | A feature is impaired but still usable, or a reasonable workaround exists. | A filter returns wrong results but a manual sort recovers them. |
| Low | Cosmetic issues, edge cases, and minor annoyances with no functional impact. | A misaligned icon, a typo, or a tooltip that renders a beat late. |
The two rules that keep severity honest are simple. First, severity ignores who is affected. The moment "our biggest customer" enters the sentence, you have left severity and started talking about priority. Second, stop at four. A fifth level almost always turns into an argument about whether something is a high-Medium or a low-High, which is effort spent on the label instead of the fix.
The Four Bug Priority Levels
Priority is the triage owner's call, made with the support or product voice in the room. It ranks how soon a bug gets fixed relative to everything else. The labels vary between teams, but the four-level shape is consistent.
| Priority | Label | Meaning | Typical response |
|---|---|---|---|
| P0 | Urgent | Drop everything and fix now. | Same day, often interrupt-driven. |
| P1 | High | Fix in the current cycle. | Days, within the active sprint. |
| P2 | Medium | Schedule for an upcoming cycle. | Weeks, planned not reactive. |
| P3 | Low | Fix when convenient, or accept it. | Someday, or closed as won't-fix. |
Whatever labels you use, tie each priority level to a target response time. A priority with no attached time is just a feeling, and feelings do not survive a busy week. The support SLA management guide covers setting response targets that engineering can actually meet, which is what turns a priority label into a commitment.
Why They Are Not the Same Number
The clearest way to see the split is to line up the two decisions side by side. They differ on who makes the call, what evidence it rests on, and how often it changes.
Severity (how bad it is)
- Set by engineering or QA
- Judged on technical and user-experience grounds
- Independent of which customer is affected
- Objective and stable once set
- Answers: how broken is this?
Priority (how soon to fix)
- Set by the triage owner
- Judged on business impact and roadmap
- Depends entirely on who is affected
- Changes as customer impact moves
- Answers: what do we do next?
Two worked examples make the gap concrete:
High severity, low priority
A crash that wipes local state in a beta feature used by three internal testers. Technically severe, because data is lost and there is no workaround. Low priority, because almost no one is exposed and no revenue is at risk. It gets a real severity label so it is not forgotten, and a low priority so it does not jump the queue.
Low severity, high priority
A misaligned total on the invoice screen your largest enterprise account reviews with their finance team every Friday. Cosmetic in code terms, so low severity. But it undermines trust with a renewal-critical account, so high priority. The support voice is what carries that context into the decision.
Neither example works if severity and priority share one field. The value of two axes is precisely that a bug can sit high on one and low on the other.
The Severity-Priority Matrix
Once both levels exist, you need a rule for combining them, or every bug becomes a fresh negotiation. The matrix gives triage a consistent baseline. Read it as a starting point: set the initial priority from the cell, then let business context adjust it.
| Low impact | High impact | |
|---|---|---|
| Critical severity | High priority | Urgent priority |
| High severity | Medium priority | High priority |
| Medium severity | Low priority | Medium priority |
| Low severity | Low priority | Medium or high priority |
"Impact" is the business dimension the support voice owns: how many accounts are hit, how much revenue they represent, and whether any are near renewal. Notice the bottom-right cell. A low-severity bug on a high-impact account can still earn a high priority, which is the invoice example above and the single most common place a severity-only queue gets it wrong.
How to Assign Severity
Severity assignment is fast when the definitions are written down. The work is matching the bug to a level, not inventing the level.
- 1
Confirm the bug is real and reproducible
You cannot rate what you cannot reproduce. A report without repro steps is a lead, not a bug, so send it back for detail before assigning anything. The bug tracking template guide lists the fields that make this step quick.
- 2
Judge functional impact, not customer identity
Ask what the bug breaks and whether a workaround exists, on purely technical grounds. Keep account names out of this step. Who is affected belongs to priority, and letting it leak into severity is what corrupts the level.
- 3
Match it to the written definition
Compare the impact to your four definitions and pick the closest. If two levels feel equally right, your definitions overlap and need one sentence of sharpening, which is a one-time fix that speeds every future call.
How to Assign Priority
Priority is the harder call because it is a judgment, not a lookup. Start from the matrix, then reason through the business context. Three scenarios cover most of what a triage owner faces.
Move a bug up when it hits many accounts, a high-revenue account, or an account near renewal. A Medium-severity bug across half your base is a High-priority problem even though the code impact is modest.
When the affected accounts are unremarkable in number and value, leave priority where the matrix put it. Most bugs live here, and resisting the urge to re-litigate them is what keeps triage short.
Move a bug down when few users hit it or a clean workaround exists. A high-severity crash behind a rarely used flag with a documented workaround can wait, as long as the severity label keeps it visible.
The reason two owners matter shows up here. Engineering sets severity from the code, and the triage owner sets priority with the support voice present, so business context reaches the decision. Leave the support voice out and the queue gets ranked on severity alone, which is technically correct and commercially wrong. The bug triage process guide covers who belongs in the room in more depth.
Common Mistakes That Reorder the Queue
Where the Levels Actually Live
Severity and priority are only useful if they reach the person fixing the bug with the bug. A carefully rated report that lives in a support inbox, while engineering works from a separate tracker, has to be re-rated by hand or, more often, gets re-invented from scratch. That is where the level system quietly breaks: not in the definitions, but in the handoff.
The fix is a single record that carries severity, priority, and customer impact from the support tool into the engineering tracker intact, and keeps status flowing back so support knows when the fix ships. When support runs on HubSpot Service Hub and engineering runs on Linear, IssueLinker does exactly that. The severity and impact captured on the HubSpot ticket travel with it into a synced Linear issue in one click, and when the Linear issue changes status the ticket updates, so the priority you set survives contact with a busy week instead of dying in a Slack thread. The full pattern is in the Linear HubSpot integration guide.
Keep severity and priority attached to the bug, all the way to the fix
If support runs on HubSpot Service Hub and engineering runs on Linear, IssueLinker turns a rated ticket into a synced Linear issue in one click and keeps status flowing back, so the levels you set never get re-invented in the handoff.
What to Do This Week
If your queue feels randomly ordered, three moves fix most of it before you change any tool.
Split severity and priority into two fields
If they share one dropdown today, separate them. Give every open bug a severity and a distinct priority. The gap between the two columns is where the misranked work has been hiding.
Write four definitions for each
Critical, High, Medium, Low for severity, and your four priority labels, one sentence apiece, posted where the team can see them. Most triage debate is an argument about definitions that were never written down.
Adopt the matrix as your default
Set priority from the severity-and-impact cell, then require a named reason for every move off the default. It makes the queue defensible and the meeting short.
Severity tells you how bad a bug is. Priority tells you what to do about it. Keep them separate, define them in four levels each, and join them with a matrix, and the queue starts ordering itself around customer impact instead of recency, volume, or whoever complained loudest.
