Incident Response Readiness Checklist
A readiness check for incident response covering severity definitions, symptom-based SLO alerting, a defined incident commander, runbooks, break-glass access, and blameless postmortems with tracked action items. Best validated with a game day exercise.
When to Use This Checklist
Use this checklist when standing up an on-call practice, before a major launch, or when auditing an existing incident-response process. Incidents are inevitable; what varies is how quickly a team detects, coordinates, and recovers. This checklist verifies the foundations are in place before the next outage, not improvised during it.
How to Use This Checklist
Review the checklist with both the engineering team and whoever owns customer communication. Start with detection: alerts should fire on user-impacting symptoms tied to SLOs, not on noisy infrastructure metrics that cause fatigue. Then verify coordination: a defined incident commander role, an escalation chain, and a fast way to open an incident channel. Finally, verify learning: blameless postmortems that produce tracked action items which actually get closed.
The best validation is a game day or tabletop exercise. Simulate a failure and watch whether the team can detect it, coordinate, and recover using only the documented process.
What Good Looks Like
Severity levels are unambiguous, so anyone can classify an incident consistently. On-call engineers are paged by symptom-based alerts and reach for runbooks that cover the common failures. An incident commander coordinates while others investigate, and customer communication flows through a ready status page. Break-glass access is available for emergencies but is time-bound and logged. After resolution, a blameless postmortem captures contributing factors and produces action items that are tracked to completion, steadily reducing repeat incidents.
Common Pitfalls
Alert fatigue is the silent killer: when alerts are noisy or not actionable, real incidents get missed. Another common gap is the absence of a clear incident commander, leading to chaotic, uncoordinated response. Postmortems that assign blame discourage honesty and learning, while postmortems whose action items are never closed mean the same incident recurs. Teams also forget break-glass procedures, so emergency access becomes either impossible or dangerously unlogged.
Related Resources
Build on incident-management best practices, blameless postmortems, and symptom-based alerting. Pair on-call best practices with SLO-based detection so paging reflects real user impact.