Severity vs. Priority: Two Different Questions

Incident Response & Ticketing Workflows

Chapter 2 · Severity vs. Priority: Two Different Questions

Two words that get used almost interchangeably, and shouldn't be: severity asks how bad an incident actually is, on its own technical and business merits. Priority asks how urgently it should be worked right now, relative to everything else competing for the same attention. They usually move together — but treating them as one question instead of two is a genuine, common mistake with real downstream cost.

Two Independent Axes

Severity	Priority
How bad is the actual impact — users affected, data-loss risk, whether a core function is fully unavailable or just degraded, whether a workaround exists	How urgently this specific item should be worked right now, given everything else in the queue and the current business context
Determined by the facts of the incident itself	Determined by context and resourcing — what else is happening, who's affected and how visibly, whether waiting makes things worse
Doesn't change based on who's asking	Can shift hour to hour as circumstances change, even with the underlying severity unchanged

Why They Usually Move Together, But Legitimately Diverge

High severity usually does mean high priority — a full outage genuinely should jump the queue. But real, legitimate divergence happens in both directions:

High severity, temporarily lower priority: a rarely-used legacy reporting feature goes completely down — genuinely high severity, since it's fully non-functional. But if it happens during an all-hands-on-deck product launch window, deliberately deferring it a day is a legitimate call, not a mistake — as long as that decision is made and documented consciously, not by accident.
Low severity, temporarily higher priority: a cosmetic typo in the site footer, spotted the morning of a scheduled press announcement featuring screenshots of the homepage. The bug itself hasn't gotten any worse — it's exactly as minor as it was yesterday — but the timing makes it worth fixing in the next hour rather than the next sprint.

Neither example is a classification error. The mistake would be conflating the two axes — reading a temporarily-deferred high-severity ticket as "not that serious," or reading a temporarily-elevated low-severity ticket as "the bug itself got worse."

A First Look at the 2x2

Severity and priority as two independent axes give four broad combinations — worth naming here briefly; Chapter 3 builds a full framework around them:

Combination	What it usually means
High severity, high priority	Drop other work, address immediately
High severity, lower priority (temporarily)	Genuinely serious, deliberately deferred for a documented reason
Low severity, high priority (temporarily)	Minor on its own, urgent due to timing or visibility
Low severity, low priority	Routine backlog work

Inflating severity to force priority quietly breaks the whole scale

A genuinely common, damaging habit: marking something "critical" or "SEV1" not because it meets that bar, but because the person reporting it personally wants it worked on immediately. This is a real "cry wolf" problem — once a top severity label stops reliably meaning "genuinely catastrophic," everyone downstream starts discounting it, including the next time something actually is that severe. If a ticket is urgent for reasons unrelated to its actual technical impact, that's a priority conversation, not a reason to inflate the severity label.

Worked Example: Two Tickets, Side by Side

Ticket 1: Password reset emails failing for ~5% of requests	Ticket 2: Footer copyright typo, found morning of a press announcement
Severity: Medium — partial function loss, no data loss, a manual workaround exists (support can reset accounts directly)	Severity: Trivial — zero functional impact
Priority: Normal — work it soon, no reason to jump the queue right now	Priority: Elevated — fix within the hour, purely because of today's timing and visibility

Ticket 1 is more technically serious than Ticket 2 by every real measure, and yet Ticket 2 is the one that needs to be worked first today — a completely legitimate outcome once severity and priority are recognized as two separate questions.

Hands-On Exercises

Exercise 1

Explain why a high-severity ticket can legitimately have a temporarily lower priority, using this chapter's own legacy-reporting-feature example.

📄 View solution

Exercise 2

Explain why inflating a ticket's severity to force it to be worked sooner is described as a damaging habit, not just an inaccurate label.

📄 View solution

Exercise 3

Using this chapter's two worked-example tickets, explain why Ticket 1 is more severe but Ticket 2 needs to be worked first.

📄 View solution

Chapter 2 Quick Reference

Severity = objective impact, determined by the facts; priority = how urgently to work it now, determined by context
They usually move together, but legitimately diverge in both directions — high-sev/lower-pri and low-sev/higher-pri are both real, valid states
The mistake isn't divergence — it's conflating the two axes when reading or writing a classification
Never inflate severity to force priority — it breaks the whole scale's meaning for every future incident
Next chapter: Prioritization Frameworks: SEV Levels and the Impact/Urgency Matrix