Incident Severity Levels: How to Define SEV1 to SEV5 (With Examples)

At 2:14 a.m. the pager fires. The on-call engineer has roughly ninety seconds to answer one question before doing anything else: how bad is this? That single classification decides who else wakes up, whether the status page goes red, and whether an Incident Commander assembles a response. Get it wrong in the cautious direction and you burn an executive's sleep on a non-event. Get it wrong in the optimistic direction and a SEV1 festers as a quiet ticket while customers churn.

This is what incident severity levels are for. They are a shared, pre-agreed vocabulary that turns a panicked judgment call into a lookup. Below is a copy-paste SEV1-to-SEV5 matrix with concrete examples per level, response and SLA expectations, exactly who gets paged, and the often-blurred line between incident severity and bug priority. The conventions are drawn from PagerDuty, Atlassian, and Google SRE so you can adopt them without reinventing the taxonomy.

Severity is, in PagerDuty's framing, the technical measure of the incident's impact on a system. It answers "how broken is production right now?" and nothing else. It deliberately ignores how convenient a fix is, who is on holiday, or which release is shipping Friday. Those belong to priority, a separate axis covered below.

The reason a fixed scale matters is decision speed under stress. PagerDuty notes that properly classifying incidents can improve resolution times by as much as 40%, because a clear level instantly resolves the downstream questions of who to wake and how loudly to communicate. The level is the cheapest, fastest lever you have at 2 a.m.

Paste this into your runbook and edit the user thresholds to match your scale. The examples are concrete on purpose. Vague rubrics ("major impact") get argued about at 2 a.m.; concrete ones ("checkout returns 500 for all users") do not.

A severity label is worthless without time commitments attached. Atlassian's app severity rubric ties response targets directly to level: for major incidents (SEV1 and SEV2), response teams start an investigation within 15 minutes of being paged and publish an initial status update within 1 hour of the incident start time. Atlassian also gives a hard threshold for the top tier: a critical (C1) outage lasting more than 5 hours, or one affecting 5M+ users, is a SEV1.

The chart below shows representative time-to-first-status-update targets across the scale. Note the cliff between SEV2 and SEV3: above the line you are in real-time communications mode, below it you are in scheduled-work mode.

Treat these as ceilings, not averages. The number that matters most operationally is the 15-minute investigation start for SEV1 and SEV2: it is the clock that justifies paging a human out of bed rather than emailing a queue. If your team cannot reliably hit 15 minutes, your paging routing is broken, not your severity scale.

Severity decides the size of the response. At the top of the scale the page is not a single person but a role structure. Google SRE's Managing Incidents model separates command from work: the Incident Commander holds the state and makes decisions, the Operations lead applies the actual fixes, and the Communications lead owns updates to stakeholders and the public. Keeping these roles distinct prevents the classic failure where the one person typing fixes is also the one person trying to answer the VP's Slack messages.

Map paging to level explicitly so nobody improvises mid-incident:

• SEV1: immediate page to on-call, auto-assemble IC + Comms + Ops, notify executives and customers.
• SEV2: page on-call and IC, update the status page, notify internal stakeholders.
• SEV3: high-urgency page to the owning service team only.
• SEV4: low-urgency page worked above normal tasks.
• SEV5: no page; a ticket is the entire response.

The fastest classifications are the ones a machine pre-computes. A short, version-controlled function makes the rubric auditable and removes 2 a.m. ambiguity:

This is where most teams tangle three different vocabularies. They are genuinely different things, used by different people, at different moments:

• Incident severity (SEV1–SEV5) classifies a live operational event for paging and communications. Owned by on-call/SRE, set in seconds.
• Bug severity (CRITICAL/HIGH/MEDIUM/LOW) classifies a defect in your tracker. Owned by QA/reporter, used to order the backlog.
• Priority (P0–P3) is the business scheduling decision: how fast we choose to fix it.

PagerDuty draws the cleanest line: severity is the technical measure of impact; priority is the business assessment of how quickly the issue needs to be fixed. They usually correlate, but a crashed staging database is high technical severity and low business priority. A SEV1 postmortem typically produces CRITICAL bug tickets, but a CRITICAL bug found in QA is not a SEV1, because nothing is on fire in production yet. For the backlog side of this story, see our companion playbook on bug severity vs priority.

Every incumbent in this space, PagerDuty, Atlassian, Better Stack, Rootly, incident.io, assumes a human reads dashboards and assigns the level by hand. That works, but it puts the hardest judgment (blast radius, error signature, affected-user count) on a sleep-deprived responder who is guessing.

BugMojo's wedge is the input side. Its browser extension captures rrweb session replay, console logs, network requests, and screenshots, and its MCP server lets an AI agent (Claude Code, Cursor) read that full debugging context and propose a severity classification, pre-filling the blast radius, error signatures, and affected-user signals that human responders normally estimate under pressure. No top-10 incumbent connects severity assignment to agent-readable capture context.

Honest limits: BugMojo is not an incident-management platform. It does not run your on-call schedule, manage escalation policies, or own your status page, so it does not replace PagerDuty or incident.io for paging and rotations. It feeds better signal into whatever paging tool you already run. Use it to make the SEV proposal sharp; keep your existing tool for the rotation.

Adopt the scale in one sitting with this list:

• Start with three levels. SEV1 outage, SEV2 major degradation, SEV3 minor. Add SEV4/SEV5 only once you need to split "fix this hour" from "file a ticket."
• Write concrete examples per level from your own product, not generic ones.
• Attach SLA targets: 15-min investigation start and 1-hr first status update for SEV1/SEV2.
• Define paging per level explicitly in the runbook, including the IC/Ops/Comms roles for SEV1.
• Adopt the "if unsure, go higher" rule in writing.
• List your finite SEV1 criteria (Google SRE keeps this short on purpose) so escalation is unambiguous.
• Map SEV to bug severity so postmortems produce correctly-labeled tickets.
• Run an abbreviated postmortem for SEV2/SEV3 and a full one for SEV1.