On this page5 sections
MatrixBeginner4-6 min reference

Bug Severity vs Priority

Severity and priority are two different axes that people constantly collapse into one. Severity = how badly it breaks the product (technical impact). Priority = how soon it must be fixed (business urgency). A bug can be high on one axis and low on the other. This sheet is the quick decision aid — the full triage process and report templates are linked below.

The two axes

AxisOwned byAsksExample values
SeverityQA / EngineeringHow much functionality is lost?S1 Critical · S2 Major · S3 Minor · S4 Cosmetic
PriorityProduct / PMHow urgently must we fix it?P1 Urgent · P2 High · P3 Medium · P4 Low

Severity × Priority matrix

P1 — UrgentP2 — HighP3/P4 — Lower
S1 CriticalCheckout down in prodCrash behind an unreleased flagCritical bug in a deprecated feature
S2 MajorLogin fails for a user segmentBroken CSV exportEdge-case error few users hit
S3 MinorWrong price shown on pricing page*Misaligned button on key flowMinor validation quirk
S4 CosmeticTypo in the company name on launch day*Padding off by 2px on heroConsole warning, no user impact

* Low severity, high priority — these are the ones the single-field model gets wrong: trivial to fix technically, but business-urgent.

When to use

Reach for this during triage, bug write-up, and release sign-off when you're deciding what blocks the release versus what ships to the backlog.

Common mistakes

  • Using one field for both — losing the "cosmetic but urgent" and "critical but can wait" cases.
  • Letting the reporter set priority; priority is a business call, severity is a QA/Eng call.
  • Inflating severity to force a fix (use priority for urgency instead).
  • No agreed scale — define S1–S4 / P1–P4 once and put it in the bug template.

Evidence to capture

Repro steps, environment, the user/segment impacted, frequency, and a screenshot or log. Severity follows from impact + frequency; priority follows from who's affected and when.