What is Severity?

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.

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.

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 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.