Severity Classification
Classifying bugs as Critical, High, Medium, or Low — and understanding severity vs. priority
Severity levels
- Critical (P0/S1) — system down, core function broken, no workaround, data loss, security breach
- High (P1/S2) — major feature broken, workaround exists, or significant subset of users affected
- Medium (P2/S3) — feature degraded but usable, minor data issue, cosmetic in critical path
- Low (P3/S4) — cosmetic issues, typos, minor UX polish
- Severity = technical impact; Priority = business urgency — they are different
Question 0 of 5
A bug causes the payment processing to fail for 100% of users in production. No workaround exists. What severity level is this?
Critical — core business function broken, 100% of users affected, no workaround. Severity levels:
- Critical (P0/S1): System down or core function unavailable, data loss, security breach — needs immediate fix, may require on-call escalation
- High (P1/S2): Major feature broken but workaround exists, or subset of users affected
- Medium (P2/S3): Feature degraded but usable, minor data issues, cosmetic in critical path
- Low (P3/S4): Minor cosmetic issues, typos, nice-to-have improvements
What is the difference between severity and priority in bug reporting?
Severity = technical impact; Priority = business urgency. They can diverge:
- High severity, Low priority: A critical crash in a deprecated feature used by 2 customers — technically severe but business deprioritises it
- Low severity, High priority: A typo in the CEO's name on the homepage — technically minor but fix before the press conference
A user reports: "The tooltip in the settings panel appears 2px too far to the right." What severity is this?
Low — minor cosmetic issue, no functional impact. How to classify cosmetic bugs:
- Does it prevent the user from completing a task? → If no, it's not Critical or High
- Is the affected element in the critical path (checkout, login, data entry)? → If not, it's likely Low
- Is the visual deviation significant (missing data, misleading label, overlap blocking content)? → If a 2px offset, it's cosmetic
A bug in the admin dashboard causes exported CSV files to have one column shifted by one position. The workaround is to use the API directly. What severity is this?
High — the feature is broken and the workaround is non-trivial. Reasoning:
- Data is wrong (incorrect CSV columns) — this is a data integrity issue, not cosmetic
- Users relying on exports for reporting, importing into other tools, or compliance will be affected
- Workaround exists but requires API access — excludes most non-technical admins
When should a bug be marked as Won't Fix?
Won't Fix = fix cost or risk exceeds impact, or it is intentional. Valid Won't Fix scenarios:
- By design: "Expected behaviour for this edge case per spec"
- Too risky: "Fix would require refactoring a critical payment flow with no test coverage"
- Not worth it: "Affects 0.001% of users in a deprecated browser"
- Out of scope: "This is a known browser limitation we cannot control"