Incident severity levels (SEV1 to SEV5), explained

Incident severity levels are a fixed scale that ranks how badly an incident affects users, from SEV1 at the top to SEV5 at the bottom. The level a responder assigns is not paperwork. It decides who gets paged, how fast they have to move, who needs to be told, and how much of everything else can wait.

Without a scale, every incident is negotiated from scratch under pressure, and the loudest voice tends to win. With one, a responder can look at what is happening, match it to a written definition, and know within seconds how hard to push.

Why severity levels exist

The point of a severity scale is consistent, fast triage. It answers three questions before anyone has to think:

• How urgent is this? A full outage and a typo on a marketing page are not the same emergency, and the response should not be either.
• Who responds? Higher severity pulls in more people, and often wakes them up. Lower severity waits for working hours.
• Who gets told? A SEV1 might warrant a public status update and a note to leadership. A SEV4 usually needs neither.

The scale turns those judgement calls into a lookup. That is what makes it useful at 3am, when judgement is exactly the thing in short supply.

The SEV1 to SEV5 scale

The most common convention runs from SEV1 (most severe) to SEV5 (least). Some teams stop at SEV3 or SEV4, and the exact wording varies, but the shape is consistent. Here is a widely used version.

• SEV1: critical. A full outage or a severe data or security incident. Most or all users are affected, core functionality is unavailable, and there is no workaround. This is an all-hands response, usually paged immediately at any hour, often with a public status update. A complete site outage, a data breach, or payments failing across the board all land here.
• SEV2: major. Significant impact to a core feature, but not a total outage. A large group of users is affected, or a critical function is badly degraded, though a partial workaround may exist. It needs an urgent response, but not always the whole team out of bed. One key service down while the rest of the product works is a typical SEV2.
• SEV3: minor. A limited or moderate problem. A non-critical feature is broken, or a small subset of users is affected, and a workaround usually exists. It is handled during working hours by the responsible team without paging anyone.
• SEV4: low. A small issue with little user impact. A cosmetic bug with a workaround, a minor performance dip, or a problem on a rarely used path. It goes into the normal backlog and is scheduled like other work.
• SEV5: cosmetic. Trivial issues with no functional impact: a visual glitch, a typo, a misaligned element. It is tracked and fixed in due course, with no urgency at all.

The scale is deliberately blunt. Under pressure, a small number of clearly defined levels is faster to apply and harder to argue about than a long, precise one.

Severity is not priority

These two words get used interchangeably, and they are not the same thing.

Severity measures impact: how badly the incident hurts users right now. Priority measures sequence: the order in which you actually work on things. They usually track together, but not always. A low-severity bug that only affects one major customer might still be worked at high priority for business reasons. A cosmetic issue on your most-visited page might jump the queue even though its severity is low.

Keeping the two separate lets you say "this is a small problem that we are choosing to fix first" without pretending it is an emergency.

SEV numbering versus P numbering

You will also see incidents labelled P1, P2, P3 and so on. This is the same idea with different letters, though P more often refers to priority than to raw severity. Some teams use both: a severity level for impact and a priority level for scheduling. Others collapse them into one scale. Neither is wrong. What matters is that everyone in your organisation reads the same label the same way, so pick one convention and write it down.

How to assign a severity

The cleanest way to classify an incident is to combine two factors: how bad the impact is, and how many people it reaches.

• Impact: is the feature completely down, badly degraded, or just cosmetically off?
• Scope: is this hitting everyone, a segment, or a single user?

A total failure affecting everyone is unambiguously your top level. A cosmetic glitch affecting one user is your bottom. Most real incidents sit in between, which is exactly why written examples matter more than definitions. Two responders should be able to look at the same event and land on the same level. If they routinely disagree, your definitions are too vague or you have too many levels.

Assign the level early, and revise it as you learn more. Incidents often start looking like a SEV3 and turn out to be a SEV1 once the real blast radius is clear. Upgrading is normal and expected, not a failure of the first call.

Severity drives the response

The whole point of the number is what happens next.

• Paging versus a ticket. High severity pages a human immediately, through the channel they actually watch. Lower severity becomes a tracked task. Getting a real alert to the right place fast is its own discipline; see uptime alerts in Slack and Discord and the Slack integration for how to wire that up, plus the wider view of downtime alerts.
• Detection feeds classification. You cannot assign a severity to an incident you have not noticed. Automated uptime monitoring is what surfaces the failure in the first place, and confirming it across regions tells you whether it is real and how widespread it is.
• Severity affects recovery time. A clear level means less time spent debating scope and more spent fixing, which pulls down your mean time to recovery.
• Severity affects your commitments. Major incidents are the ones that eat into the availability you have promised. How that promise is defined is covered in what is an SLA.

Getting started

You do not need a heavy process to benefit from this. Start with three to five levels, write one plain-language definition and one real example for each, and make them easy to reach when an incident hits. Refine the wording after your first few incidents, when you can see where responders hesitated. Severity levels are also the backbone of a broader incident response plan, which wraps roles, communication and a review around the scale.

Start monitoring free, no credit card, so the incidents you are classifying reach you the moment they start instead of after a customer complains.