Skip to main content
OpsRoadmaps

Checklists / incident-response

Incident Response Checklist

From alert to resolution: assign command, communicate early, decide severity honestly, learn without blame.

9 steps · 9 required · last reviewed (next review 2027-03-19) · updated 2026-09-21

Related focus areas:IncidentOpsResilience EngineeringSRE

Roadmaps covering the same ground:AWS Security ImprovementIncident Management MaturityObservability MaturityPlatform Engineering AdoptionProduction-Ready KubernetesResilience and DR ImprovementSRE Adoption

Sign in to run this checklist

Run this the moment an incident is declared — the first five minutes set the trajectory of the next five hours. It encodes the roles and sequencing that keep incidents coordinated instead of chaotic.

The counterintuitive item is communicating early: status page updates with no new information still measurably reduce duplicate reports, angry escalations, and social media speculation. Say what you know, say when you'll update, update.

  1. Incident commander is named — one person coordinates, others execute

    required

    Without a single coordinator, everyone investigates and nobody decides; the commander does not touch the keyboard.

  2. Severity is assigned against the documented scale (with activation criteria)

    required

    Severity decided by feel drifts; severity decided by criteria drives who gets woken, what comms go out, and when leadership engages.

  3. Dedicated incident channel is opened and linked from the alert

    required

    Context scattered across DMs cannot be coordinated and cannot be reviewed afterwards.

  4. Customer communication goes out early — even 'we are investigating'

    required

    Silence is interpreted as incompetence; a timestamped 'we know, we're on it' halves inbound noise and buys time.

  5. Mitigation is preferred over diagnosis when users are hurting (rollback, flag-off, failover)

    required

    Understanding why is valuable tomorrow; stopping the bleeding is valuable now. Mitigate first, diagnose after.

  6. Timeline is being scribed as events happen (timestamps, actions, observations)

    required

    Memory rewrites itself within hours; the scribe's log is the only honest input to the postmortem.

  7. Recent deploys/config changes are listed and tested first

    required

    The last change is the cause the large majority of the time — check it before exotic theories.

  8. Resolution is verified by the customer-visible metric, not by the fix 'working'

    required

    The deploy succeeded and the error rate is still elevated means the incident is not over.

  9. Blameless postmortem is scheduled within 48 hours with action items tracked to closure

    required

    An incident whose actions never close will recur; blameless is what makes people report the next one early.

Run it against your real gaps

A checklist is most useful when you know which controls you are actually missing. A free OpsRoadmaps assessment scores your controls with explainable findings and builds a roadmap from the results.

Assess my stack

Checklists document self-reported practice. Items were last reviewed 2026-09-19 — adapt them to your own environment.