Incident severity and command roles: impact, coordination and handoffs
Classify incident impact without pretending severity labels are universal. Assign command, technical and communication roles, then practice escalation and a precise shift handoff.
TL;DR: Severity should communicate current or credible user impact and determine response urgency. Assign one coordinator, explicit technical workstreams and a communication owner so responders can act without competing changes or abandoned updates.
Severity is a local contract
Organizations use different severity names and numbering. Define the impact criteria before using a label in an interview. A widespread purchase failure, limited degradation and a latent risk might require different urgency even when the same subsystem is involved.
Use affected users, critical workflows, duration and potential data or security impact. Infrastructure size alone is misleading: one failed dependency can block the main business workflow, while many failed batch workers may only delay nonurgent work.
Google's incident-response workbook describes coordination and role separation. Adapt the roles to team size without implying every organization follows identical titles or a fixed staffing count.
| Role | Main responsibility | Boundary to preserve |
|---|---|---|
| Incident coordinator | Set priorities, track decisions and assign work | Avoid becoming the sole keyboard operator |
| Technical lead or workstream owner | Investigate and execute approved mitigation | Report evidence and changes to coordination |
| Communication owner | Publish confirmed impact and update commitments | Avoid inventing recovery estimates |
| Recorder when available | Maintain timeline, decisions and outstanding questions | Record uncertainty as uncertainty |
In a small response, one person may hold multiple roles temporarily. Name that explicitly and hand off a role as the incident grows.
Route information toward one operational picture
The coordinator need not approve every diagnostic read. They should prevent conflicting mitigations and ensure consequential changes have an owner, expected effect and observation plan.
Worked example: a regional checkout failure
Suppose customers in one region cannot complete checkout, while browsing and other regions remain healthy. Start with the affected workflow and cohort. Do not label it minor simply because global CPU looks normal or because only one region is affected.
Assign one workstream to confirm impact and recent changes, and another to evaluate a safe traffic or release mitigation. The coordinator records which change will occur first and who watches the result. Simultaneously changing DNS, database configuration and application version would make both causality and rollback harder to establish.
If the cohort expands or data integrity becomes uncertain, revise severity and resource allocation immediately. A severity change reflects new evidence. It should not require defending the initial label as though it were a personal prediction.
After a mitigation, verify the checkout outcome from the affected region and compare error/latency recovery with backlog state. Mitigation before diagnosis can restore service while a technical explanation remains incomplete. Communicate those as separate milestones.
Escalation should request a specific contribution
“Need database help” is less useful than “We need someone authorized to inspect the primary's replication and failover state; application retries are increasing connection pressure.” State what evidence or action is missing and why it matters now.
Keep access authority explicit. A coordinator can prioritize response without automatically possessing permission to delete resources, disable security controls or expose customer data. The team's emergency process should define those decisions before an incident.
External dependencies also need ownership. If a vendor issue is suspected, assign someone to collect relevant evidence and manage that escalation while internal mitigation continues. Waiting for a vendor response should not silently stop every other workstream.
Handoff transfers the active state
A shift handoff should include confirmed impact, mitigations already attempted, current system state, dangerous operations in progress and the next decision checkpoint. Identify the incoming coordinator and obtain an explicit acknowledgment. A long chat transcript is useful history but a poor substitute for this operational state.
The communication cadence concept explains updates and uncertainty. After stabilization, postmortem actions can address recurring coordination gaps, including missing owners and untested emergency permissions.
Should the most senior engineer always command? Choose someone able to coordinate effectively. A specialist may contribute more by investigating a critical subsystem while another responder manages the overall incident.
Can an incident be severe before exact user counts are known? Yes, when credible evidence shows a critical workflow or serious risk. State the uncertainty, gather scope evidence and revise the classification as facts improve.
When can severity be reduced? After evidence shows impact and remaining risk meet the lower category's criteria. A completed deployment command alone is insufficient proof of recovery.