Incident postmortem template: a blameless format your team will actually finish

The incident is over, the graphs are green, and everyone wants to get back to work. Two weeks later the postmortem is still a half-filled doc with a timeline that stops at "investigating," three action items without owners, and nobody quite sure where the file lives. Six months after that, the same failure happens again and someone asks, "didn't we have an incident like this before?"

Here is a blameless template you can paste in today, a filled example, a short meeting format, a fast way to rebuild the timeline from Slack and GitHub, and the habits that get action items done.

What a postmortem is for

The Google SRE book defines a postmortem as a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root causes, and the follow-up actions to prevent it from recurring. Atlassian's incident handbook uses almost the same four parts.

Two ideas from those sources shape everything below:

• Decide the triggers before the incident. Google lists common triggers such as user-visible downtime beyond a threshold, any data loss, on-call intervention like a rollback, resolution time above a threshold, and a monitoring failure. Atlassian requires postmortems for severity 1 and 2 incidents and makes them optional otherwise. Pick your own rule and write it down, so nobody has to argue about whether this one "counts."
• Blameless means you fix systems, not people. Google's chapter says a blameless postmortem assumes everyone "had good intentions and did the right thing with the information they had." Atlassian puts the key question well: not "why did individual x do this," but why the system allowed it or made it look like the right thing to do. In practice, Atlassian refers to people by role ("the on-call payments engineer") rather than by name in the write-up.