A blameless postmortem is a written review of an incident that explains how the system allowed the failure rather than who caused it. This page gives you the record itself — nine sections in Excel, Word and PDF — plus the three parts teams most often skip and what goes wrong when they do. No signup, no email.
Download the postmortem template
Same nine sections in all three formats. The Excel version has the timeline and action items as tables you can sort; the PDF is for printing and filling in during a review when nobody wants a laptop open.
Postmortem Template — Excel (.xlsx)
One sheet per incident. Timeline and action items as real tables. Works in Excel, Google Sheets and LibreOffice.
Download .xlsxPostmortem Template — Word (.docx)
For teams whose reviews are documents — paste into Confluence, Notion or a wiki without losing the structure.
Download .docxPostmortem Template — PDF (print)
Printable A4 for the review meeting itself, then transcribed into whatever your team keeps records in.
Download .pdfWhat the nine sections are for
Nothing here is exotic. The value is in keeping the parts separate, because each one answers a different question and they fail in different ways.
| Section | What goes in it | How it fails |
|---|---|---|
| 1. Summary | Two or three sentences someone outside the team can follow: what broke, for whom, how long, what ended it. | Written in internal shorthand, so it is unreadable six months later — when it is most needed. |
| 2. Impact | Users affected, failed requests, duration, SLA or revenue consequence, what customers actually saw. | Adjectives instead of numbers. “Significant degradation” cannot be compared to any other incident. |
| 3. Timeline | Timestamps in one timezone, the event, and how you knew — alert, graph, deploy record, message. | Reconstructed from memory. Entries without a source drift toward the version that makes sense in hindsight. |
| 4. Detection | How it surfaced, and the gap between impact starting and anyone knowing. | Skipped entirely, which hides the number that usually matters most. |
| 5. Contributing factors | The conditions that all had to be true at once. Systems, defaults, missing signals, decisions made with the information available then. | Collapsed into one root cause, discarding the cheap fixes. |
| 6. What went well | What you want to keep and fund. | Treated as morale filler and dropped. |
| 7. Where we got lucky | What worked this time but is not guaranteed to work again. | Deleted before circulation, because it reads as an admission. |
| 8. Action items | Typed prevent / detect / mitigate, with an owner, a date and a ticket. | All prevent, no owner, no ticket. Expires quietly. |
| 9. Follow-up | How you will know the actions worked, and a review date. | Missing, so nobody ever finds out. |
What “blameless” means in the record itself
Blameless is not a tone of voice and it is not a promise nobody will be embarrassed. It is a constraint on the writing: describe people by role and decision, not by name and mistake, and describe every decision with the information that was available at the time rather than what you know now.
The practical reason is not kindness. An engineer who expects to be named in a document that reaches their manager stops volunteering the detail that makes a timeline accurate — the command they ran, the alert they dismissed, the assumption they made. Those details are the investigation. Lose them and you are left describing what the dashboards saw.
Two sentences show the difference:
| Blaming | Blameless | Why the second one is more useful |
|---|---|---|
| The on-call engineer ignored the disk alert. | The disk alert fires roughly forty times a week, almost always without consequence, and is routinely acknowledged without investigation. | The first sentence supports one action: talk to that engineer. The second supports fixing the alert threshold, which fixes it for everyone. |
| The deploy was pushed without following the checklist. | The checklist lives in a wiki page that is not linked from the deploy tool, and the deploy path does not require it. | The first blames a person for a system that made the shortcut easier than the procedure. |
A quick test before you circulate: if a section can only be acted on by speaking to one individual, it is not finished. Keep asking why that action was reasonable to that person at that moment until you reach something you can change — a default, a threshold, a missing guardrail. That is the same discipline as 5 Whys, applied to the write-up instead of the meeting.
The three sections teams skip
The source column in the timeline. Most timelines are written the day after from Slack scrollback and memory, and memory reorders events to make them coherent. Requiring a source per entry — alert ID, graph, deploy record, message link — changes what the timeline is: evidence rather than narrative. It also surfaces the entries nobody can source, which are usually the interesting ones.
Where we got lucky. The section that gets cut before circulation, because it sounds like an admission. It is the highest-value paragraph in the document. “The failover worked because the secondary happened to be in the region that stayed up” is a finding: next time it will not happen to be. Luck you have not written down is indistinguishable from resilience you have built.
Typing the action items. Ask of each action: does this stop the cause (prevent), find it sooner (detect), or reduce the damage while it happens (mitigate)? Lists that are all prevent are the norm, and they are a signal — prevention is the ambitious answer, detection is usually the shippable one. An incident that took ninety minutes to notice and ten to fix has a detection problem, whatever the trigger was.
Where root cause analysis fits inside the postmortem
The template is the record; it does not analyse anything for you. Section 5 is where a method earns its place:
| Situation | Method | Why |
|---|---|---|
| Single failure with a short causal chain | 5 Whys, blameless | Fast, needs no data set, produces a chain reviewers can follow |
| Several candidate factors, cross-functional group | Fishbone | Surfaces conditions across categories before anyone commits to one |
| Symptom appears in some places and not others | Is / Is Not | The boundary between affected and unaffected is itself the evidence |
| Recurring class of incidents, need to pick what to fix | Pareto analysis | Ranks by frequency or cost so the work targets the vital few |
| Failure that has not happened yet but could | FMEA | Turns the postmortem into design input for the next system |
Not sure which fits? The RCA method selector asks four questions and names one.
The part that decides whether any of it mattered
A postmortem is finished when its actions are done, not when the document is circulated. Actions that live only inside the document are the ones that expire — the review is over, the incident is cold, and nobody is looking at that page again. Give each one an owner who is a person rather than a team, a due date, and a ticket in the system the team already works from. Then use the review date in section 9 to check them against the criterion you wrote when you created them.
What happens in those ninety days is its own subject: why RCA fixes stall after the meeting covers the five ways actions decay and the cadence that keeps them alive.
FAQ
What is a blameless postmortem?
A written review of an incident that explains how the system allowed the failure rather than who caused it. It records what happened, when it was detected, what contributed, and what will change — describing people by role and decision rather than by name and mistake. The point is not politeness: engineers who expect to be named stop volunteering the details that make a timeline accurate.
What should a postmortem template contain?
Nine parts cover almost every incident: a summary a stranger can follow, measured impact, a timeline where every entry names its source, how it was detected, contributing factors, what went well, where you got lucky, action items typed prevent / detect / mitigate with owners and dates, and a follow-up check with a review date.
What is the difference between a postmortem and a root cause analysis?
The postmortem is the document and the meeting around a specific incident; root cause analysis is the method used inside it. A postmortem without a method usually produces a timeline and a task list. A method without a postmortem produces a finding nobody outside the room ever reads.
Should a postmortem name a single root cause?
Usually not. Incidents in distributed systems are the product of several conditions that were all true at once — a latent defect, a missing alert, a deploy at a bad hour, a runbook that did not match reality. Forcing that into one root cause discards the others, and those are often the cheapest to fix. That is why the template says contributing factors.
How do you write a postmortem timeline?
Every entry needs a timestamp in one timezone, what happened, and how you know — alert, graph, deploy record, message. Entries without a source are reconstruction from memory. Include the moment impact started, not just when somebody noticed; the gap between them is your detection time.
What are prevent, detect and mitigate action items?
Prevent stops the cause recurring. Detect finds it sooner. Mitigate reduces the damage while it is happening. A list that is all prevent usually means the detection gap was never discussed — and detection work is often faster to ship.
How do you keep postmortem action items from being forgotten?
Owner who is a person, not a team. Due date. Ticket in the system the team already works from. Then a review date on the postmortem itself, checked against the acceptance criterion you wrote when you created the action. Actions tracked only inside the document are the ones that quietly expire.
Related
- 5 Whys for DevOps — how to run the blameless review this record comes out of
- Corrective action tracking — the ninety days after the meeting
- Is / Is Not analysis — when the symptom appears in some places and not others
- RCA report template — the method-agnostic investigation record
- Corrective action plan — owners, dates and verification that hold up
- Root cause analysis: complete guide