Skip to main content
SEV levels are a numbered scale for classifying incidents by the severity of their impact, with the lowest number the most critical and higher numbers progressively less serious. Rootly’s default scale runs from SEV0 to SEV3; many teams start at SEV1 instead. Assigning a SEV level sets the response in motion proportionally: it determines who gets paged, how quickly, whether leadership is notified, and how often updates go out. “SEV” is simply shorthand for “severity.”

​
Why do SEV levels exist?

Without a shared scale, every incident starts with a negotiation: is this bad? Whom should I bother? SEV levels replace that negotiation with a lookup. Once an incident is labeled SEV0, nobody debates whether it deserves a dedicated incident channel or an executive update—the label carries the playbook with it. The scale also makes reporting possible: “we had three SEV0s this quarter, down from seven” is a meaningful sentence only if SEV0 means the same thing every time. The numbering convention runs opposite to intuition for newcomers: lower number = worse incident. A SEV0 is an emergency; a SEV3 is a ticket.

​
What does a typical SEV scale look like?

There is no universal standard. Your severity levels are a company policy, and every organization tunes the definitions. The following four-level scheme matches the levels Rootly ships with and is a common starting point: Two design choices matter more than the exact wording. First, definitions should be observable—“affects more than X% of customers,” not “really bad”—so two responders reach the same answer. Second, each level must map to concrete response behavior; a severity that changes nothing about the response is just decoration. In Rootly, severity levels and their notification behavior are configured under severities. Security incidents usually run through the security team’s own process rather than this scale, with tighter access and different communication rules. Rootly’s private incidents keep that work visible only to the people who need it.

​
How are SEV levels used during an incident?

The initial SEV is assigned during triage, in the first minutes, using whatever is known at the time, and it is explicitly provisional. The person declaring picks a starting level; once an incident commander joins, the commander owns it. Teams should upgrade or downgrade freely as facts emerge, since scope frequently looks different twenty minutes in. Best practice when uncertain: round up. Over-calling a SEV1 costs some interrupted evenings; under-calling one costs response time during real customer impact. A realistic sequence: at 14:02 an engineer sees checkout errors in one region and declares a SEV1. At 14:15, monitoring shows the failure spreading to a second region and the error rate doubling, so the commander upgrades to SEV0, which automatically pages additional responders and notifies leadership. At 14:40 a rollback contains the issue and impact drops to a single degraded feature; the commander downgrades it back to SEV1 for the remainder of the response. Each change re-tunes the machinery without anyone renegotiating from scratch.

​
How do SEV levels differ from P-levels?

Many teams also use P-levels (P1, P2, P3…), and the two scales are easy to conflate. Strictly speaking, severity measures impact—how bad it is—while priority measures order—what gets worked on first. They usually correlate but can diverge: a SEV2 bug with a contractual deadline might be P1 work, while a technically severe issue in a deprecated system might be deliberately low priority. In practice, plenty of organizations use “P0” and “SEV0” interchangeably for incidents; what matters is picking one scale for incident classification and defining it precisely. The distinction is unpacked further in severity vs priority. Browse all definitions in the incident management glossary.