Incident Severity & Roles

Severity levels classify incidents by business impact and urgency so the organization responds proportionately. A common scale: SEV1 — critical, widespread outage or data loss, all-hands response; SEV2 — major functionality broken for many users; SEV3 — partial/degraded impact; SEV4 — minor issue, low urgency. Severity drives everything downstream: who is paged, whether an incident commander is assigned, communication cadence, and whether a postmortem is required. Clear, agreed criteria prevent debates about severity during an incident, when speed matters most.

The incident commander owns the coordination of the response, not the technical fix. Borrowed from emergency services' Incident Command System, the IC maintains the big picture, makes and delegates decisions, prevents duplicated or conflicting efforts, and ensures communication flows. Critically, the IC should not be heads-down debugging — that is the job of subject-matter experts (the "ops" or resolver role). Separating coordination from hands-on work keeps the response organized, especially in large SEV1s where many people are involved and chaos is the default.

In a significant incident, the communications lead (or "comms lead"/scribe) handles the flow of information outward and keeps a timeline. They post regular updates to the status page, brief leadership and support teams, and translate technical status into stakeholder-appropriate language. This role is vital because, without it, either responders get constantly interrupted by "what's the status?" questions (slowing the fix) or stakeholders are left in the dark (eroding trust). Separating comms from the technical resolution lets each role do its job well.

SBAR (originally from healthcare/aviation) is a structured handoff format that keeps incident updates clear and complete: Situation (what is happening right now), Background (relevant context leading up to it), Assessment (what we think the cause/impact is), and Recommendation (what we propose to do or need). Using a consistent structure prevents rambling, ensures no critical element is omitted, and is especially valuable for shift handoffs or when escalating — the receiver gets exactly the information they need to act, fast.

A blameless postmortem examines an incident to understand the systemic contributing factors — gaps in tooling, process, monitoring, or design — rather than finding someone to punish. The rationale is practical, not merely kind: if people fear blame, they hide details, omit their mistakes, and the organization fails to learn, so the same failure recurs. Blamelessness assumes people acted reasonably given what they knew, and asks how the system let a reasonable action lead to failure. The output is concrete, owned action items — not a scapegoat.