📝 How to Write a Blameless Postmortem (With a Copy-Paste Template)

Most teams don’t need another lecture on why postmortems matter. They need a repeatable process and a template they can paste into a doc at 2pm the day after an incident, when everyone is tired and half the team wants to move on. This guide is that process and that template.

The goal of a blameless postmortem is narrow and unglamorous: make the next incident less likely, or less painful, or both. Everything below serves that goal. If a section of your postmortem doesn’t move you toward prevention, faster detection, or smaller blast radius, cut it.

The process, before the template

A template is only as good as the process that fills it in. Here’s the sequence I follow.

1. Assign an author within 24 hours. One named person owns the document. Not “the team” — a person. They don’t have to have all the answers; they have to drive the document to completion.

2. Reconstruct the timeline first, from evidence. Before anyone writes a narrative, pull the raw facts: alert timestamps, deploy logs, chat scrollback, graph screenshots. The timeline is the spine of everything else. Build it from artifacts, not from memory.

3. Draft alone, review together. The author writes a first pass solo. Then the responders review it in a meeting. Committee-authored first drafts are slow and mushy; solo drafts reviewed by the group are sharp.

4. Separate facts from analysis. The timeline is what happened. The root-cause section is why. Keep them apart so readers can trust the facts even if they disagree with the analysis.

5. Land the action items in a tracker before you call it done. A postmortem whose action items live only inside the doc is theater. More on this below.

What “blameless” means in practice

Blameless does not mean you avoid naming what people did. It means you assume every person acted reasonably given the information they had at the time, and you investigate why the system allowed a reasonable action to cause harm.

“An engineer ran a schema migration that locked the orders table” is a neutral fact. “An engineer carelessly locked the orders table” is blame. The first invites the real question — why could a single migration lock a production table with no guardrail? — and the second shuts the conversation down. Write facts about actions; investigate the system around them.

The copy-paste template

Drop this into your incident wiki. Keep the headings identical across every postmortem so readers always know where to look.

# Postmortem: [Short incident name]

- **Incident ID:** INC-XXXX
- **Date:** YYYY-MM-DD
- **Duration:** HH:MM (first impact → full recovery)
- **Severity:** SEV-X
- **Author:** [Name]
- **Reviewers:** [Names]
- **Status:** Draft | In review | Final

## Summary
Three to four sentences for someone who wasn't there. What broke, who
was affected, how long it lasted, and how it was resolved. No jargon.

## Impact
Quantified. Requests failed, customers affected, revenue at risk, SLO
budget burned, internal teams blocked. Replace "some users" with numbers.

## Detection
How did we find out? Automated alert, customer report, or an engineer
noticing? Record the gap between when it started and when we knew.

## Timeline (all times UTC)
| Time  | Event                                             |
|-------|---------------------------------------------------|
| 14:02 | Deploy of orders-service v2.3.1 begins            |
| 14:06 | Orders API p99 latency climbs past 3s             |
| 14:11 | First automated alert fires                       |
| 14:14 | On-call acknowledges, opens incident channel      |
| 14:29 | Root cause identified: migration holding a lock   |
| 14:33 | Migration killed, service recovers                |
| 14:40 | Full recovery confirmed, incident closed          |

## Root cause(s)
The chain of conditions that produced the incident. Plural on purpose.
Name the trigger and the contributing factors that let it become an
outage.

## What went well
Protect what's working. If the rollback path worked, or an alert fired
correctly, say so before you start changing things.

## What went wrong / where we got lucky
The honest section. Include near-misses: "the alert fired, but if the
on-call had been paging for the other service we'd have missed it."

## Action items
| # | Action item                          | Owner | Type    | Ticket   | Due   |
|---|--------------------------------------|-------|---------|----------|-------|
| 1 | Add pre-deploy lint blocking locking migrations | A. R. | Prevent | JIRA-101 | 07-25 |
| 2 | Alert on orders p99 > 800ms for 2m   | B. K. | Detect  | JIRA-102 | 07-20 |
| 3 | Add statement_timeout to migrations  | C. L. | Mitigate| JIRA-103 | 07-30 |

## Lessons / systemic themes
One or two sentences on what this incident says about the broader system.

Filling in the hard sections

Root cause. Resist the urge to stop at the first answer that feels like a person. “The engineer pushed a bad config” is where bad postmortems end. Keep going: why did a bad config reach production? Because there was no validation between merge and deploy. That’s the finding you can actually fix.

Action items. Every item needs four things: it must be specific (“add an alert on X”), owned by one person, tracked in a real ticket with a due date, and classified as prevent, detect, or mitigate. If every item is a “prevent” and there are no “detect” items, you’ll be just as blind the next time something slips through.

Impact. Vague impact makes future prioritization impossible. “Checkout error rate peaked at 38% for 22 minutes; roughly 4,100 customers saw a failed payment” tells a reader whether this class of incident deserves a quarter of engineering time. “Some users were affected” tells them nothing.

Common mistakes

• Writing it too late. Memory decays fast. Draft the timeline within a day while the chat logs and graphs still make sense.
• Passive voice to hide actors. “It was decided to skip the canary” hides a decision worth understanding. Name it neutrally.
• A single root cause. Real incidents are multi-causal. One “the” root cause discards the rest of the chain.
• Action items with no owner or date. These are wishes, not commitments.
• No “what went well.” Skip it and you risk “fixing” the parts that saved you.

Wrapping up

A blameless postmortem is a process, not a document. Assign an author, build the timeline from evidence, draft solo and review together, and don’t call it done until the action items live in a tracker with owners and dates. Paste the template above into your wiki and use it on the next incident — consistency is what makes postmortems fast to write and easy to read.

Related

• How to Write a Blameless Postmortem That People Actually Read
• Running Incident Retrospectives: A Facilitator’s Template
• Postmortem Anti-Pattern: The Single Root Cause Fallacy