Incident response checklist
A step-by-step incident response checklist — detect and declare, stabilize, communicate, resolve, and the after-action review that makes it count.
Last updated
Your ticks are saved on this device only — never uploaded, never synced.
Detect & declare
0/5Stabilise
0/4Communicate
0/4Resolve
0/4After
0/4Questions
Who should declare an incident?
Anyone who suspects one. Making declaration cheap and blameless is what removes the hesitation that turns a ten-minute problem into an hour — a false alarm costs a few minutes and is worth paying repeatedly.
Why stabilise before diagnosing?
Because users are affected while you investigate. Rolling back or failing over restores service and leaves the cause available to study afterwards, which is almost always the right order.
How often should updates go out?
On a stated interval, even when there is nothing new — every thirty minutes is a common choice. Silence is read as nothing being done, and it generates the interruptions that slow the response further.
What makes a postmortem blameless?
Asking what made the mistake possible rather than who made it. People who expect blame withhold detail, and the withheld detail is usually the part that would prevent a recurrence.
When is an incident actually over?
When service is restored and the follow-up work is written down and owned. Closing at restoration is how the same incident happens twice, because the temporary fix becomes the permanent one.