Incident Postmortem Checklist
A blameless postmortem template as a checklist: timeline, impact, contributing factors, action items and follow-through. Start it when an incident closes.
- Typical schedule per incident
- The checklist 5 sections, 18 items
- Variables
{{incident_title}} - Start from CI
Use this checklist after any incident that affected customers, triggered a high severity, or nearly did. Near misses are often the cheapest lessons. It does not replace your postmortem document. It makes sure the document gets written, reviewed and, most importantly, that its action items actually get done.
Who owns it
A postmortem owner, often the incident commander, owns the run from the first draft to the last closed action item. They gather the facts and run the review meeting. They do not decide all the fixes alone. Each action item gets its own owner.
Common pitfalls
- Blame in disguise. "Human error" is a starting point, not a conclusion. Ask what made the mistake easy to make and hard to notice, and fix that.
- One root cause. Most incidents have several contributing factors: a change, a missing alert, an unclear runbook. Listing only one hides the others.
- Waiting too long. Chat logs scroll away and memories fade. Draft the timeline within a few working days.
- Action items without owners. "Improve monitoring" will never be closed. Each item needs a concrete change, an owner and a due date.
Keep it blameless
Describe what people saw and why their actions made sense at the time. People share more when they are not afraid of being judged, and that leads to better fixes.
Start the run when the incident is resolved, so it never depends on someone remembering. The run stays open until the last action item is checked.
The checklist: Postmortem: {{incident_title}}
Gather facts
-
Postmortem owner named and review meeting scheduled
-
Timeline built from chat, alerts, deploy logs and status page updates, with timestamps
Include detection, escalation, each mitigation attempt and resolution.
-
Customer impact quantified: who was affected, how, and for how long
Use real numbers from logs or support tickets, not estimates.
-
Detection reviewed: how was the incident noticed and how long did that take
-
Responders asked for their view before the meeting
Analyse
-
Contributing factors listed: technical, process and organisational
-
Each factor explained with "how did this make sense at the time", not who is to blame
-
What went well recorded, so it is kept
-
Draft document reviewed by at least one responder for accuracy
Review meeting
-
Meeting held with responders and owners of affected systems
-
Action items agreed, each with a concrete change, an owner and a due date
Prefer fixes that prevent or detect the problem automatically over "be more careful".
-
Action items prioritised against other work by the team lead
Publish
-
Postmortem published where the whole team can find it
-
Customer-facing summary sent or posted optional
Useful after major outages. Keep it factual, without internal names.
-
Runbooks, alerts and on-call documentation updated with the lessons learned
Follow through
-
Action items created as tickets and linked in the postmortem
-
Open action items reviewed at the next team meeting
-
All action items closed or explicitly dropped with a reason
Checklist as Markdown
Start this checklist from your pipeline
When an incident is resolved in your tooling, POST /api/v1/runs with template "Postmortem: {{incident_title}}" and the incident title.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Postmortem: {{incident_title}}", "variables": {"incident_title": "…"}}'Frequently asked questions
What should a postmortem template include?
A good postmortem covers a summary, impact, a timeline, contributing factors, what went well, and a list of action items with owners and due dates. Keep the document short enough that people will actually read it. The action items are the part that matters most.
What does blameless postmortem mean?
A blameless postmortem looks at how the system and the process allowed the incident to happen, rather than who made a mistake. It assumes that people acted reasonably with the information they had. This makes people more open about what really happened, which leads to better fixes.
When should a postmortem be written?
Start within a few working days of the incident, while logs and memories are fresh. Hold the review meeting within a week or two. Define in advance which incidents need one, for example every customer-facing outage and every high-severity incident.
Updated