Incident Severity Levels: Defining SEV-1, SEV-2, and SEV-3

When an incident starts, one of the first questions is “how bad is this?” Severity levels exist to answer that consistently — so response effort matches real impact instead of whoever happens to be loudest. A well-defined severity scale is one of the highest-leverage things a team can agree on before the next outage.

What severity levels are for

Severity classifies how much an incident matters. That classification drives everything downstream: how many people get pulled in, whether it’s an all-hands response or a business-hours fix, how often you communicate, and whether you wake anyone up.

Without agreed levels, every incident becomes a negotiation. One engineer treats a minor degradation as a five-alarm fire; another shrugs off a genuine outage. Severity replaces that inconsistency with a shared vocabulary, so the response scales to the problem automatically.

The common scale: SEV-1, SEV-2, SEV-3

Most teams use a three-tier scale (some add a SEV-4 or SEV-5 for the smallest issues). The exact wording matters less than agreeing on it in advance.

• SEV-1 — Critical. A core service is unavailable, or data is at risk. Broad customer impact with no workaround. This is an all-hands, drop-everything response, day or night.
• SEV-2 — Major. Significant degradation, or a key feature broken for many users. Serious, but with a workaround or partial availability. Urgent, but not necessarily a middle-of-the-night page.
• SEV-3 — Minor. Limited or partial impact, a workaround exists, few users affected. Handled during business hours without emergency escalation.

The jump between levels should reflect a real jump in impact, not a small gradient. If your SEV-1 and SEV-2 responses look identical in practice, the boundary isn’t doing any work.

Define severity by customer impact

The single most important rule: classify by customer impact, not by how hard the fix looks or how alarming the internal symptoms are.

A subtle bug that silently corrupts customer data can be a SEV-1 even if the fix is one line. A dramatic-looking alert storm on an internal system with no user-facing effect might be a SEV-3. Anchoring severity to impact — how many users, how core the function, whether there’s a workaround, whether data integrity is threatened — keeps classification honest and comparable across very different incidents.

An example severity matrix

A matrix makes the boundaries concrete. Adapt the thresholds to your product:

Level	Scope of impact	Availability	Response
SEV-1	Core service down or data at risk	No workaround	All-hands, immediate, any hour
SEV-2	Key feature broken for many users	Partial or workaround exists	Urgent, dedicated responders
SEV-3	Minor or partial, few users	Workaround exists	Business hours, normal queue

Publishing something like this — with a couple of real examples per row — gives responders a reference they can apply in seconds rather than debating definitions while the clock runs.

Keeping classification consistent

Even with a matrix, severity is a judgment call under pressure. A few habits keep it consistent:

• Write the definitions down and make them easy to find. A severity scale that lives in one person’s head isn’t a standard.
• Classify early, and allow re-classification. Set an initial severity fast to trigger the right response, then adjust up or down as you learn more. Severity is not a one-time verdict.
• When in doubt, round up. It’s safer to over-respond and stand down than to under-respond and lose time. Downgrading is cheap; a missed SEV-1 is not.
• Review severity in postmortems. Ask whether the level was right in hindsight. Consistent misclassification is a signal your definitions need tuning.

Consistency also depends on the rest of your response being predictable. Severity feeds directly into ownership, escalation, and communication, so it works best as part of a defined process. Our incident management guide covers how severity fits into the full lifecycle, from detection through blameless learning.

Make severity part of the incident, not an afterthought

Severity is most useful when it’s a first-class attribute of the incident itself — set at declaration, visible to everyone responding, and preserved in the record. When severity, ownership, and the timeline live together, the level you assign actually shapes the response instead of sitting in a side channel.

That’s how EverUptime’s incident management treats it: severity is captured on the incident, drives who gets pulled in, and stays in the preserved history for review. Start free or book a demo to see it on your own services.