Bug severity vs priority: what's the difference?

Almost every bug tracker ships with both fields, and almost every team fills them in the same way — high, high, high — until the fields stop meaning anything. The confusion is understandable, because in casual speech "critical" and "urgent" are synonyms. In a bug tracker they are not.

Severity: how much damage does it do?

Severity describes the bug itself. It answers: when this happens, how bad is it for the person it happens to? It does not care how many people that is, how often, or what else your team is working on.

The useful discipline here is that severity should be answerable by the person who hit the bug, without knowing anything about your roadmap. If a field can only be filled in by someone who knows what ships next quarter, it is not severity.

Priority: how soon will you fix it?

Priority describes your response. It answers: relative to everything else waiting, when does this get worked on? That requires context the reporter usually does not have — who is asking for it, what is already in progress, what is contractually due, and what your team can absorb this week.

Priority is therefore a scheduling decision, not an observation. It changes as circumstances change. A bug filed as low priority in January can become urgent in March because a customer who cares about it just renewed. The bug did not change; the business context did. Severity, by contrast, only changes if you learn the damage was worse than you thought.

The four combinations, and what to do with each

The reason both fields exist is that the interesting cases are the ones where they disagree.

High severity, high priority

Checkout is broken for everyone. Nobody argues about this one. Stop what you are doing.

High severity, low priority

A crash that destroys unsaved work — but only in an admin screen two people use, on a browser you are dropping support for next month. The damage is real and serious, which is why severity stays high and you do not talk yourself out of it. But almost nobody will meet it, so it waits. This combination is the main argument for keeping both fields: it lets you record "this is genuinely bad" without committing to fix it today, and without quietly downgrading the bug to make the queue look tidier.

Low severity, high priority

Your company name is misspelled on the home page. Nothing is broken, no data is at risk, and severity is honestly trivial. You will still fix it before lunch. Anything cosmetic but highly visible — a landing page, a demo you are giving on Thursday, pricing that reads wrong — lands here.

Low severity, low priority

The backlog. Be honest that this is where most bugs live, and be willing to close things that will realistically never be scheduled. A backlog nobody believes in is worse than a short one.

Who sets which

The split matters more than the labels:

• The reporter sets severity. They saw what happened and can describe the damage. Asking them to also judge urgency invites guessing.
• The lead or product owner sets priority. It needs knowledge of everything else in flight.

When one person does both — common on small teams — the fields stop carrying independent information, which brings us to the practical question.

Does a small team need both?

Usually not, and this is where a lot of small teams go wrong by copying process built for organisations ten times their size.

Below roughly ten people, the person who finds a bug is often the person who decides when it gets fixed. Two fields set by the same person at the same moment will always agree, because there is no second perspective to disagree with. You get the ceremony of a triage process with none of the information.

One field is enough. Call it priority, because that is the question you actually act on, and let severity live in the description where it belongs — "this loses unsaved work" is more useful in a sentence than as a dropdown value. Add severity as a separate field when reporters and schedulers genuinely become different people: when support files bugs that engineering schedules, or when customers report directly.

This is the reasoning behind BugTrack shipping a single priority field — low, medium, high, critical — rather than two. It is built for teams of one to twenty, where a second field would mostly be filled in out of obligation. If you outgrow that, you have outgrown the tool, and that is a fair trade for not carrying process you do not need.

Making the field mean something

Whichever fields you keep, they only work if they discriminate. Three habits help:

• Cap the top level. If more than about one bug in ten is critical, the label has stopped working. Some teams cap it literally: no more than three open criticals, and raising a fourth means demoting one.
• Write the definitions down where people file bugs, not in a wiki nobody opens. Four sentences is enough.
• Re-price, don't argue. Priority is allowed to change. Treating it as a promise makes people fight over the initial value; treating it as a current estimate makes triage quick.

Frequently asked questions

Is severity or priority more important?

Priority, if you only keep one — it is the field that decides what happens next. Severity informs priority but does not determine it.

Should customers set priority?

No. Customers can tell you how badly something hurts them, which is severity plus context. Priority requires weighing their bug against everyone else's, which only you can see.

What about "blocker"?

A blocker is neither — it is a dependency statement, meaning something else cannot proceed until this is done. If you use it, treat it as a flag rather than the top of the priority scale, or it will swallow the scale.