· 9 min read
Bug triage 101: severity, priority, status
A clear vocabulary for triaging bugs. Severity, priority and status mean different things — keeping them separate is what makes a queue manageable.
Triage is the daily act of looking at incoming bugs and deciding what happens next. Done well, it takes 10 to 20 minutes and clears the queue. Done badly, it becomes a weekly two-hour meeting that nobody enjoys and that resolves half as much. The difference is almost always vocabulary.
Three words do most of the work: severity, priority and status. They sound similar; they answer different questions; teams that conflate them argue forever about which bug to fix first. Teams that separate them just fix bugs.
Severity — how bad is it
Severity is a property of the bug itself: how much damage it causes when it fires. It does not change based on roadmap, customer, or who is asking. A data-loss bug is critical whether one user or one million hit it.
- Critical — data loss, security incident, total outage, irreversible damage.
- High — core flow broken, no workaround, blocks a paying customer.
- Medium — feature degraded, workaround exists, affects some users.
- Low — cosmetic, edge case, only visible to one persona.
Write your definitions down in a shared doc. Severity drift is the single biggest cause of triage arguments: one engineer's Medium is another's High because they never agreed on the threshold.
Priority — when will we fix it
Priority is a decision the team owns. It is the answer to "when do we work on this?" — informed by severity but also by roadmap, customer commitments, release schedule, and resource availability. A high-severity bug on a feature nobody uses can still be low priority. A low-severity bug that blocks a launch demo can jump to high.
- P0 — drop everything, fix now, ship a hotfix.
- P1 — in the next release.
- P2 — in the next quarter.
- P3 — when convenient, may be closed as won't-fix.
Status — where is it now
Status answers "what is happening with this ticket today?". Keep the set small — anything more granular tends to drift, with bugs sitting in "Awaiting design review" for six months because nobody owns the transition.
- New — filed, not yet looked at.
- In progress — actively being worked on by a named owner.
- Review — code review or QA verification.
- Done — shipped, verified, closed.
If you need more nuance, add it in comments or labels, not as new statuses. The four above cover 95% of bug lifecycles.
The triage meeting that actually works
Fifteen minutes, daily for active products, weekly otherwise. One person drives, one person updates the tracker live. Everyone else watches and chimes in on severity or owner disagreements.
- Filter to status = New, sort by date.
- For each bug: confirm reproduction, set severity, set priority, assign owner.
- Move to In progress if work starts today, otherwise leave in New with priority set.
- Skip bugs you cannot reproduce — comment with what you tried, bounce to reporter.
- End the meeting when New is empty or when the timer hits 15 minutes, whichever comes first.
Make the history visible
Hidden activity logs erode trust between QA and dev. When status changes are inline on the bug — author, timestamp, old → new state — anyone who lands on the link sees the full story without asking. "What is happening with this bug?" stops being a Slack question.
dontslowme exposes the current status prominently and tucks the full history one click away. The card shows the latest change, the panel shows the timeline. Reporters can self-serve the answer instead of pinging the engineer.
Anti-patterns to watch for
- Every bug filed as Critical or High — severity inflation makes the field meaningless.
- Bugs that stay in In progress for weeks — either close them or reset to New.
- "Won't fix" without a comment — the reporter deserves an explanation.
- Triage meetings that run over — the queue is too long; do a backlog cleanup separately.
- Custom statuses per project — the team forgets which means what across projects.