What is Severity?

#How severity levels work

A typical scale runs from SEV1 for complete unavailability or critical data risk, through SEV2 for major functionality broken for many users, SEV3 for partial degradation with a workaround, down to SEV4 for minor issues with no meaningful user impact.

Each level maps to concrete expectations: response time, whether responders are paged outside business hours, who is notified, and whether a postmortem is required. Without those mappings, severity is a label that changes nothing about the response.

#Why severity matters

Severity is what makes prioritization possible when several things are wrong at once.

• Response calibration: effort matches actual impact rather than who noticed first.
• Communication scope: each level defines who is informed, and the exact audience varies by organization and incident.
• Resource allocation: the severe incident gets the people.
• Consistent trending: incident counts by severity are comparable over time.

#Limits and calibration problems

Severity inflation is the most common failure. When every incident is filed as SEV2, the classification stops distinguishing anything and the scale is dead. Severity deflation happens too, usually where a high severity triggers an unpleasant review process that people prefer to avoid.

Initial classification is also made with incomplete information. Severity should be revised as scope becomes clear, and teams need to make upgrading mid incident routine rather than treating it as an admission that the first call was wrong.

#Severity vs priority

Severity describes impact: how bad is this for users right now. It is a property of the incident.

Priority describes what gets worked on first, combining severity with effort, risk, and what else is happening. A SEV3 affecting a customer in an active contract negotiation may take priority over a SEV2 with a workaround in place. Conflating the two produces either ignored high severity issues or over resourced low impact ones, and keeping them separate lets both signals do their job.

#Key takeaways

• Severity levels must map to concrete response expectations, or the label changes nothing.
• It enables prioritization when multiple incidents compete for the same responders.
• Inflation kills the scale; deflation usually indicates that high severity carries an unpleasant process cost.
• Severity is impact and priority is work order, and conflating them distorts both.

#Frequently asked

How many severity levels should a team use?

Three or four. More levels produce debate about classification without changing the response.

Who decides severity?

The responder or incident commander, using the impact criteria. Making it a judgment call by committee delays the response.

Can severity change during an incident?

It should. Initial classification uses incomplete information, and revising it as scope becomes clear is expected behavior.