Incident severity levels

A severity level is a short label for how bad an incident is. Its real job is to decide what happens next: who is paged, how fast, who else has to be told, and whether a postmortem is required. If two severities trigger exactly the same response, you have one too many.

A common scale

Many teams use four levels. Names vary. You might see SEV1-SEV4, P1-P4, or Critical/High/Medium/Low. Some count from SEV0. The names matter less than consistency. Everyone must use the same definitions.

Level	What it means	Example	Response
SEV1	A core service is down or data is at risk for many users	Checkout fails for everyone; data is being lost	Page immediately, any hour. Incident commander. Status page update. Postmortem required
SEV2	A core service is badly degraded, or down for some users	Checkout is slow or fails for one region	Page immediately, any hour. Status page if users notice. Postmortem usually
SEV3	A minor feature is broken, or a problem has a workaround	Report export fails; retry works	Notify in working hours. Fix in normal work
SEV4	Cosmetic, or no user impact yet	A disk will fill in two weeks	Ticket. No notification

Writing definitions that work

Define severity by user impact, not root causes. "Checkout fails for all users" is a severity. "Database CPU is high" is a cause. It could map to any level. Use examples from your own system. People decide faster by comparing to a known case. They do not read abstract definitions.

State who can change the level. Severity often shifts as you learn more. The incident commander should raise or lower it without debate.

When unsure, choose the higher level. Downgrading a SEV1 that turns out small costs little. Treating a real SEV1 as a SEV3 costs a lot.

Severity and priority

Severity measures impact. Priority measures urgency. A severe internal tool issue at the weekend may have high severity but low priority. Most teams with one on-call rota do not need both. One scale that drives the response is enough.

Connecting severity to alerting

An alert usually arrives before anyone has judged severity. There are two common ways to connect them:

1. Set severity on the alert rule. Each rule carries a label such as severity=critical or severity=warning, and the on-call tool maps it to an urgency. Prometheus alerting rules commonly carry a severity label for this.
2. Set severity when declaring the incident. The responder picks a level after looking. The alert only decides whether to page.

Both work. The important part is that only the top levels page someone at night. See how to design an escalation policy.

Checklist

• Three to five levels, each with a different response.
• Each level defined by user impact, with a real example.
• It is written down who pages, who communicates and when a postmortem is required, for each level.
• Alert rules carry a severity or urgency label.
• Only the top one or two levels page outside working hours.