Bug Severity vs Priority: Examples

Severity describes the observed impact of a bug on a task or system. Priority records when a team decides to address it relative to other work. A severe defect can be scheduled later when it is rare and a tested workaround exists; a minor defect can move earlier for a real deadline. Neither label follows from a status code or screenshot alone.

First record the affected audience, failed task, frequency, and workaround. Then a named owner can choose an order using the available evidence and revisit it when the evidence changes. Microsoft’s Azure Boards bug guidance describes severity as a subjective impact rating and priority as resolution order; it also gives a rare crash with lower priority as an example. Its numeric choices belong to that product’s process, not every team.

This matrix is an example conversation aid, not a universal P1 scale, service-level agreement, or automatic score. Your team defines its own labels and response policy.

Take the fictional intermittent crash: the first report has one failure and an apparently working menu path. A later verified report shows data loss or that the menu path also fails. Keep the original impact note, add the new observation and tested conditions, then ask the decision owner to reassess severity and priority separately. The Azure Boards guidance treats these as distinct fields; neither should be silently rewritten as though the first decision used the later facts.

In the decision note below, make the revisit trigger concrete, such as “another confirmed crash on the current release” or “workaround fails in retest.” This gives the next reviewer a condition to check without inventing a universal priority score.

Keep the impact observation separate from the ordering decision. State what evidence would change either assessment, who owns the decision, and when they will revisit it. Do not invent a frequency, user count, or fix when the report does not establish one.

Issue: [observed failure and affected task]
Severity / impact: [what happens, to whom, and what is still unknown]
Priority / order: [team's chosen next slot and why]
Evidence: [release, steps, frequency, expected versus actual result]
Workaround: [tested path, or Not known]
Decision owner and revisit trigger: [person/team; new evidence or deadline]

Use the editable bug triage worksheet to record an actual team decision. If evidence is missing, build reproduction steps and a bug report; the fictional sample reports show fuller handoffs.

Published October 9, 2026. Updated October 10, 2026. The three cases and the matrix are invented teaching examples; teams set their own levels and deadlines.