Q9 of 38 · Manual & exploratory
What is severity vs priority in a bug report?
Short answer
Short answer: Severity describes the technical impact — how badly the system is broken. Priority describes the urgency — how quickly we should fix it. They're independent: a low-severity typo on the homepage can be high-priority; a critical crash in a rarely-used admin tool can be low-priority.
Detail
Severity is graded against the system: does it crash, corrupt data, block users, degrade functionality, or just look ugly. Common scales run S1 (blocker / data loss / outage) through S4 (cosmetic). Severity is largely the engineer's call because they know the technical scope.
Priority is graded against the business: how urgent is the fix, given customers, contracts, deadlines, and PR risk. P1 (drop everything) through P4 (fix when convenient). Priority is largely the product manager's or stakeholder's call because they know the business context.
The cross-product is where it gets interesting:
- High severity, high priority — a checkout crash on Black Friday. Obvious.
- High severity, low priority — a crash in an admin panel that only fires when a flag the admins never use is enabled.
- Low severity, high priority — the company name is misspelled on the homepage during a press cycle. Trivially fixable but visible.
- Low severity, low priority — a tooltip is mis-aligned by 1px.
Most bug-tracking tools default to grouping these as "severity-priority" — a habit worth questioning, because confusing them leads to fixing the wrong things first.