Postmortem Templates — A Field Guide

Most postmortem templates I've seen fail for the same reason: someone copied a well-designed template from a blog post, but the team never adopted the philosophy behind it. The document has a "root cause" field, so people write a root cause. It has an "action items" field, so people write action items nobody owns. The template was never the hard part — the hard part is building a process where people write down what actually happened, including their own mistakes, because they trust it won't be used against them.

Blameless is a mechanism, not a mood

"Blameless" gets treated as a tone requirement — be nice in the meeting — when it's actually a structural claim about where failure lives. A engineer fat-fingering a config value is not the interesting fact; the interesting fact is that the system let one person push an unreviewed config change to production with no validation and no staged rollout. If your postmortem's conclusion is "so-and-so should be more careful," you've stopped one level too early. The useful version asks why the system made that mistake easy to make and costly when made, and fixes that.

This isn't about protecting feelings for their own sake. It's that a team who believes honesty about their own mistakes will be punished starts writing postmortems that route around the truth — vague timelines, passive voice, contributing factors quietly omitted. You lose the exact information you built the process to capture, and you lose it permanently, because nobody tells you what really happened a second time.

What belongs in the template

A template earns its place by making the right information hard to skip. The sections that consistently matter:

• Impact statement — concrete scope: which customers, what percentage of traffic, how long, in numbers someone outside the incident can understand. "Checkout was degraded" is not an impact statement; "38% of checkout requests returned 500 for 22 minutes, roughly 900 failed orders" is.
• Timeline — detection, escalation, mitigation, resolution, each with a timestamp and who did what. This is usually the most tedious section to write and the most valuable to read six months later, because it's the only part that shows how the response actually unfolded versus how people remember it unfolding.
• Contributing factors, not a single root cause. Real incidents are almost always a stack of things that each seemed fine alone: a missing alert, a retry storm, a dependency that changed behavior, an on-call engineer working from stale documentation. Five whys is a fine prompt for getting past the first, most obvious answer, but the output should be a list of factors, not a single sentence that lets everyone else off the hook.
• What went well — genuinely useful, not a courtesy section. If a dashboard caught the problem before customers complained, or a runbook worked exactly as written, that's worth knowing too, because it tells you what to keep funding.
• Action items with an owner and a due date. An action item with no owner is a wish. "Improve monitoring" is not an action item; "Add a p99 latency alert on the checkout service, owner: , due: " is.

The performative paperwork trap

The predictable failure mode once a postmortem process exists is that it becomes a compliance artifact. A severity-1 happens, the template gets filled in because the process says it must, it gets a rubber-stamp review in a meeting nobody prepared for, and it's filed away. Nobody reads it again unless the same outage happens twice — at which point someone finds the old postmortem, groans, and notices the action items from last time were never done.

You can usually tell a team has crossed into performative territory when postmortems get written faster than the underlying systems change. If your last ten postmortems recommend "add more monitoring" and none of that monitoring exists yet, the document isn't driving anything — it's a ritual you perform to close out the incident emotionally, not a mechanism for improving the system.

Tracking action items to completion

The postmortem document itself is the easy 20% of the process. The other 80% is a lightweight system that makes action items visible until they're done: a shared board, a label in the issue tracker, a standing five minutes in a weekly review where someone reads off what's still open and how old it is. Action items that live only inside the postmortem document, with no separate tracking, have a predictable half-life of about one sprint before they're forgotten.

Some teams review postmortem action-item completion rate as an actual metric — not to punish slow teams, but because a completion rate near zero is itself worth investigating. It usually means the action items were unrealistic, unowned, or competing with feature work that always wins by default. That's useful information about your prioritization process, and you only get it if someone is counting.

Wrapping up

A postmortem template is not the point. The point is a process that gets people to write down what actually happened, including the parts that are uncomfortable, because they trust that honesty leads to a better system rather than a worse performance review. Build the template around impact, timeline, contributing factors, and owned action items — then spend the real effort on tracking those action items to completion, because a postmortem whose recommendations never ship is just a well-formatted description of a problem you're going to have again.