Bug triage: severity vs priority, and why confusing them breaks your queue

Most broken bug queues share one root cause: the team is using a single field to answer two different questions. Severity answers "how bad is this when it happens?" Priority answers "when do we work on it?" They correlate, but they are not the same axis — and every place they diverge is exactly where a one-field triage process makes the wrong call.

The classic examples: a crash in a feature two customers still use is high-severity but low-priority. A typo in the pricing page headline breaks nothing and should be fixed today. A memory leak that needs a weekly restart is low-severity and — if it is masking worse — surprisingly high-priority.

Severity should be assignable from the bug report alone, without a business discussion: does it crash, corrupt data, block a workflow, degrade it, or merely annoy? That makes severity objective enough to automate — a triage system that reads the report, the stack trace, and the affected module can set it consistently.

Priority is where judgment lives: how many users, which users, is there a workaround, what does it cost per day unfixed, what does the roadmap say. Severity is an input to priority — never a substitute for it.

Plot severity against priority and the queue sorts into four quadrants with obvious handling. High/high: drop everything — this is incident territory. High-severity/low-priority: schedule deliberately, and write down why it can wait, because that reasoning will be questioned later. Low-severity/high-priority: the reputational fixes — cheap, visible, do them now. Low/low: close or backlog honestly, rather than letting them rot at "P3" forever.

The quadrant language also ends the most common triage argument. "This is a P1!" usually means "this matters to me" — the 2×2 lets you agree it is severe while explaining why it is not first.

Triage every new bug within a business day — not fix, triage. An untriaged bug queue is a queue nobody can trust, because nothing in it has a meaning yet. Timebox the decision: severity, priority, owner, done. Deep diagnosis happens after routing, by the right person, not during triage by whoever got there first.

Deduplicate before anything else. Error storms and repeat reports mean the same defect files itself many times in different words; triaging each copy separately wastes the queue’s scarcest resource. And keep severity definitions written next to the queue — the moment they live in someone’s head, every triage becomes a negotiation.

The slow part of bug triage is not choosing a label — it is building the context to choose: what module is this in, is it new or a regression, have we seen it before, who owns that code. A human does this by reading, searching, and asking around. That is the part worth automating.

FlowTux triages with the codebase attached: when a bug arrives — from Slack, from a Sentry storm already deduplicated to one ticket, from a user report — Tux AI surfaces the likely files involved, flags whether it matches a known issue, sets severity from observed impact, and routes to the owner of that module, with the reasoning logged on the ticket. Humans keep the priority call — that is the judgment part — but they make it with the diagnosis already attached.