Blameless postmortem template
Plain Markdown, no signup, paste it into whatever your team already writes in. Each section says what belongs in it and -- more useful -- what to write when the evidence doesn't say.
The template
# Incident postmortem: <one-line title> | Field | Value | |---|---| | Severity | sev1 / sev2 / sev3 / sev4 | | Impact started | YYYY-MM-DD HH:MM UTC | | Impact ended | YYYY-MM-DD HH:MM UTC | | Author | | | Reviewers | | | Status | draft / reviewed / published | ## Summary Two to four sentences: what broke, who noticed, how long it lasted, how it ended. Write this last, once the sections below are settled. ## Impact What users and internal teams actually experienced. Use numbers only where they were measured (error rate, share of requests, duration). Write "not measured" rather than estimating. ## Timeline (UTC) | Time | Source | What happened | |---|---|---| | | deploy / alert / log / metric / human note | | | | | | One row per event, and every row traceable to a recorded artifact: an alert, a log line, a deploy, a message in the incident channel. Do not reconstruct from memory afterwards. ## Detection How the incident was noticed and how long after impact began. An alert, a customer report, someone looking at a graph -- say which, and cite the timeline row. ## Root cause The condition that, had it been absent, would have meant no incident. Cite the timeline rows or artifacts that establish it. If the evidence does not establish it yet, write exactly: > Not established by the recorded evidence. and leave it. An honest gap is more useful than a plausible guess. ## Contributing factors What made it worse, longer, or harder to see: a missing alert, a retry storm, a stale runbook, a limit nobody knew about. One bullet each, each cited. - ## Resolution What actually stopped the impact (rollback, config revert, failover) and at what time. Keep this separate from the permanent fix, which belongs under action items. ## Action items | Action | Owner | Due | Ticket | |---|---|---|---| | | | | | Every item has exactly one owner and a date. An action nobody owns will not happen. ## What went well - ## Lessons -
Why “blameless” is a structural choice, not a tone
A postmortem exists so the next incident is shorter. That only works if the people closest to the failure tell you exactly what happened, and they won't if the document is where names get attached to mistakes. So the template has no field for “who” -- only for what the systems and the recorded evidence show. This isn't our invention; it's the position of Google's SRE book, “Postmortem Culture: Learning from Failure”, which is the clearest published argument for it.
The second structural choice: every claim points at a timeline row. A root cause with no citation isn't a root cause yet, it's a hypothesis -- and the template says to write that down as such rather than promote it.
Section by section
Summarydrafted by the tool
What broke, who noticed, how long it lasted, how it ended -- in two to four sentences. Written last.
Avoid: Anything not already established further down. The summary condenses the postmortem; it doesn't add to it.
Impact
What users and internal teams experienced, with numbers where they were actually measured.
Avoid: Estimates dressed as measurements. "Roughly 28% of requests" is fine if a dashboard said so; "probably thousands of users" is not.
Timeline
One row per event, in UTC, each pointing at a recorded artifact: the alert, the deploy, the log line, the message in the incident channel.
Avoid: Reconstructing from memory a week later. If nobody wrote it down at the time, the row says so.
Detectiondrafted by the tool
How it was noticed, and the gap between first impact and first notice. That gap is often the most useful number in the whole document.
Avoid: Skipping it because detection was "obvious". It rarely is, and a customer report reaching you before your alerts did is worth recording.
Root causedrafted by the tool
The condition that, had it been absent, would have meant no incident. Cited to the rows that establish it.
Avoid: A plausible story the evidence doesn't support. Write "Not established by the recorded evidence." and leave it -- reviewers can act on an honest gap; they can't act on a guess they don't know is a guess.
Contributing factorsdrafted by the tool
What made it worse, longer, or harder to see. A missing alert, a retry storm, a limit nobody knew existed.
Avoid: Naming people. "The deploy skipped the canary step" is a factor; "Priya skipped the canary" is blame, and the next person will hide the same mistake instead of reporting it.
Resolutiondrafted by the tool
What actually stopped the impact, and when. A rollback, a revert, a failover.
Avoid: Conflating it with the permanent fix. The fix goes under action items, with an owner.
Action itemsdrafted by the tool
Concrete changes, each with one owner and a date. The tool drafts the item, its rationale and a suggested owner, each cited; the date is yours.
Avoid: "Team to consider improving monitoring." No owner, no date, no verb anyone can be asked about in a month.
A real one, filled in
The template is easier to judge with an incident in it. We filled it from Cloudflare's own published reports on two of its 2025 outages -- every line quoted verbatim and linked, nothing paraphrased -- here. For what the tool itself drafts, unedited, from three evidence entries, see the GitHub outage demo.
Where the tool fits
The six sections tagged “drafted by the tool” above are what PostMortem AI writes from your recorded evidence, each sentence cited to a timeline row, and any sentence it can't cite is dropped rather than kept. The rest -- impact, what went well, lessons, and the dates on action items -- stay yours, because they need judgment the evidence doesn't contain.
Your first incident is free. Start one or read how the grounding works.