Severity vs priority: classifying bugs without arguments

Every team that tracks bugs eventually has the argument. Someone insists the login-page typo must be fixed immediately because thousands of users see it; someone else insists the data-corruption edge case matters more even though it has affected two people ever. Both are right, and the argument is circular, because the two sides are using the same word — "important" — to mean two different things.

The fix is vocabulary. Severity and priority are different measurements, and teams that keep them separate classify bugs in seconds instead of meetings.

Severity: how bad is it when it happens?

Severity measures technical impact, independent of business context. It answers: when this bug fires, how badly does it hurt the person it hits? A workable four-level scale:

• Critical: data loss, security exposure, or a core flow completely blocked with no workaround. Checkout fails for everyone; accounts are inaccessible.
• Major: an important feature is broken, but a workaround exists. Export fails in the UI but the API still works.
• Moderate: a feature misbehaves in ways that annoy but do not block. A filter resets unexpectedly; a total displays stale for a minute.
• Minor: cosmetic. Misalignment, typos, awkward spacing.

Severity is close to objective. Two engineers reading the same report should land on the same severity most of the time, and when a report includes reproduction steps and environment details, severity can usually be assigned in under a minute.

Priority: when do we fix it?

Priority measures urgency in business context. It answers: given everything else on our plate, when does this get worked? Priority is where the messy human factors legitimately live — how many users are affected, whether a launch or a contract depends on it, whether it damages trust, whether the affected flow is strategically central or a legacy corner.

Priority is a judgment call, and it should be made by whoever owns the roadmap tradeoff — a product owner, a lead — rather than emerging implicitly from whoever shouts first.

The quadrants where they diverge

The two scales usually correlate: critical bugs tend to be urgent. The interesting cases — the ones that cause the arguments — are the corners where they split.

High severity, low priority is real: a crash in a report type used by three customers a year, in a feature being sunset next quarter, can reasonably wait despite being technically brutal. Low severity, high priority is just as real: a typo in your signup headline is cosmetically trivial and yet plausibly the most urgent bug in the tracker, because every prospective customer sees it within five seconds.

Once the team shares this vocabulary, the login-typo-versus-data-corruption argument dissolves. The typo is minor severity, urgent priority. The corruption is critical severity, and its priority depends on exposure. Both get classified, both get scheduled, nobody has to win.

Who sets what

A clean division of labor keeps classification fast. Whoever triages sets severity, because severity flows from the technical facts in the report. Whoever owns the roadmap sets priority, because priority is a resource-allocation decision. When a single person plays both roles on a small team, the separation still helps — it forces the two judgments to happen explicitly rather than blurring into a single gut call.

This is also where good reports pay off again: a report that arrives with the page URL, environment, and a screenshot supports a fast, defensible severity call. Vague reports do not just slow fixing; they slow classifying.

Practical rules that prevent drift

Three habits keep the system honest over time. First, define each severity level with concrete examples from your own product, written down where triage happens — abstract definitions rot, examples do not. Second, never let severity get quietly edited to justify a priority decision; if a critical bug is being deferred, say "critical, deferred, here is why" out loud rather than downgrading it to major to feel better. Third, revisit priorities on a cadence, because urgency changes as launches pass and usage shifts — severity, by contrast, only changes if the bug's behavior does.

Two words, two owners, two scales. It is a small amount of structure, and it replaces the least productive argument in software with a pair of quick, honest decisions.