Writing a Blameless Postmortem: Template and Example

Use this outline and keep each part concise:

1. Summary: two or three sentences on what broke, for how long, and who noticed.
2. Impact: which customers or features were affected, what they saw, and any data or money involved.
3. Timeline: timestamps in one time zone, from first signal to resolution, including when detection, escalation and mitigation happened.
4. Contributing factors: the conditions that made the failure possible or delayed recovery. Avoid a single 'root cause' unless one truly exists.
5. What went well: the detection, tooling or decision that limited damage, so you keep doing it.
6. Action items: each with an owner, a due date and a way to know it's done.
7. Lessons and open questions: things you still don't understand.

Write it as a draft within a couple of days while memory is fresh, then review it together.

Blame usually sneaks in through grammar: a person is the subject of a sentence that describes a failure. Shift the subject to the system, the process or the decision context.

• Instead of 'Sam deployed the bad migration', write 'The migration ran in production without a dry run against a copy of the data, because the pipeline doesn't require one.'
• Instead of 'The on-call engineer missed the alert', write 'The alert went to a channel that wasn't monitored overnight, and no escalation followed.'
• Instead of 'Human error', ask what made the error easy: a confusing command, missing guardrail, or unclear runbook.
• Instead of 'We should be more careful', write a concrete change, such as a required approval or a safer default.

Describe what people knew at the time, not what you know now. Hindsight makes decisions look obviously wrong, and the review is meant to learn why they looked reasonable then.

Circulate the draft beforehand and use the meeting to fix gaps, not read aloud. Invite the people involved plus someone from outside the incident who can ask naive questions. The facilitator's job is to keep the discussion on contributing factors and to stop 'why didn't they...' questions from turning personal.

Ask three questions in order: how did we detect it and how could we detect it sooner, how did we diagnose it and what slowed us down, and how did we mitigate it and what would make that faster. Time-box the meeting and capture disagreements in the open-questions section instead of forcing consensus.

Postmortems lose value when the follow-ups vanish. Common reasons: items are vague, nobody owns them, or they compete with feature work and lose. Tighten each item until it can be checked:

• Write the change, not the intention: 'Add a required staging dry run to the migration pipeline' beats 'Improve migration safety'.
• Assign one owner and a date, and put the item in the same tracker as regular work.
• Separate quick fixes from larger investments, and be honest about which you'll do.
• Review open items at your regular engineering meeting until they close.
• Cap the list. Five real changes are better than fifteen wishes.

If an item is rejected, record that decision and the reason. Deciding not to fix something is fine when it's deliberate.

A doc template is enough to start. As incidents pile up, incident tooling can pull the timeline from chat automatically so you spend the review discussing, not reconstructing; incident.io is one product built around that workflow. Decide which incidents get a full review by severity, for example every top-severity incident and any repeat of a smaller one. The definitions are in the incident severity levels template, the response process is in the incident response plan outline, and the tooling comparison is in PagerDuty vs Opsgenie vs incident.io.