> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What Are SEV Levels? SEV1, SEV2, SEV3 Explained

> SEV levels (SEV1, SEV2, SEV3...) classify incidents by severity of impact, driving who responds, how fast, and how the incident is communicated.

**SEV levels** are a numbered scale for classifying incidents by the severity of their impact, with SEV1 conventionally the most critical and higher numbers progressively less serious. Assigning a SEV level at declaration 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 SEV1, 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 SEV1s this quarter, down from seven" is a meaningful sentence only if SEV1 means the same thing every time.

The numbering convention runs opposite to intuition for newcomers: **lower number = worse incident**. A SEV1 is an emergency; a SEV5 is a note.

## What does a typical SEV scale look like?

There is no universal standard—every organization tunes definitions, and many use only three or four levels. The following five-level scheme is a common starting point:

| Level    | Typical meaning                                                                      | Example                               | Response expectation                                                                                       |
| -------- | ------------------------------------------------------------------------------------ | ------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **SEV1** | Critical: full outage, data loss, or security breach affecting most or all customers | Payment processing down for all users | Immediate page, all-hands response, dedicated incident channel, exec notification, frequent public updates |
| **SEV2** | Major: significant degradation or a core feature broken for many customers           | Search failing for \~30% of requests  | Immediate page to owning team, incident channel, regular stakeholder updates                               |
| **SEV3** | Moderate: minor feature impaired, or a workaround exists; limited customer impact    | Export-to-CSV broken; API works       | Response during business hours, owned by one team, tracked to resolution                                   |
| **SEV4** | Low: cosmetic issues or negligible customer impact                                   | Misaligned dashboard widget           | Ticketed and prioritized in normal work; no paging                                                         |
| **SEV5** | Informational: no impact, but worth recording                                        | Near-miss caught by a canary deploy   | Logged for trend analysis and learning                                                                     |

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](/configuration/severities).

## 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. 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 SEV2 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 SEV2. At 14:15, monitoring shows the failure spreading to a second region and the error rate doubling—the commander upgrades to SEV1, 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 incident is downgraded back to SEV2 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 SEV3 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 "P1" and "SEV1" 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](/glossary/severity-vs-priority).

## Related terms

* [Severity vs Priority](/glossary/severity-vs-priority)
* [What Is Incident Triage?](/glossary/incident-triage)
* [What Is Incident Management?](/glossary/incident-management)

Browse all definitions in the [incident management glossary](/glossary).