Blameless Incident Postmortem: Template + Worked Example

A postmortem is the cheapest reliability investment you will ever make, and the easiest to do badly. Done well, it converts one painful hour into a durable set of fixes the whole org can see. Done badly, it becomes a blame ritual that teaches engineers to hide problems — which guarantees the next outage is worse.

This is the operational version: a copy-paste template, a fully worked example with real numbers, and a clear line between a single root cause and the contributing factors that actually explain most failures. It is built on two of the most-cited public sources on the topic, Google's SRE book and PagerDuty's incident-response docs, and it ends with how an AI agent can draft the first version from captured evidence.

PagerDuty's blameless guidance is blunt about why this matters. It explicitly rejects the 'old view' that people's mistakes cause failure, and reframes human error as a symptom of a systemic problem. The practical move is in the grammar: steer the write-up toward 'what' and 'how' questions and away from blame-attributing 'why did you' questions. PagerDuty cites Etsy as a blameless pioneer, and the logic is self-interested rather than soft — an engineer who fears punishment will give you a vague, defensive account, and you cannot fix a system you cannot see honestly.

The number is not an argument for ceremony. It is an argument for a process so light that doing one is never the bottleneck. If a postmortem takes a week of meetings, teams skip them under pressure — exactly when the lessons are most valuable. The template below is meant to be filled in by one owner in an afternoon, then reviewed by the group, not authored by committee from a blank page.

Codifying triggers removes the worst conversation in incident response: arguing, after the fact, about whether an event 'deserves' a postmortem. If it tripped a trigger, it gets one. PagerDuty layers a severity rule on top — postmortems are mandatory for every SEV-1 and SEV-2, no exceptions — and the Incident Commander names a single postmortem owner so accountability for the document is never diffuse.

• User-visible downtime or degradation past your agreed bar (error rate, latency, availability).
• Data loss of any kind. No threshold — any is enough.
• On-call intervention: a human had to roll back, reroute traffic, or fail over.
• Resolution time over a threshold — even a contained incident that took too long to resolve.
• Monitoring failure: you found out from a customer or by chance, not from an alert.

PagerDuty's incident-response template does not have a 'root cause' box. It has Contributing Factors, plural, on purpose. The Five Whys is still a useful prompt — as long as it branches into multiple causes rather than collapsing into a single tidy chain. A good test: if your postmortem names exactly one cause and one fix, you probably stopped asking too early.

Sort contributing factors into three buckets so the action items distribute across the system, not just the code:

• Technical — the bug, the config, the missing index, the unhandled error path.
• Procedural — the runbook gap, the missing alert, the deploy that skipped staging, the unclear ownership.
• Cultural / organizational — the time pressure, the alert fatigue, the tribal knowledge that wasn't written down.

This merges the section lists from Google SRE's example postmortem and PagerDuty's template. Paste it into your incident tool, fill it in, keep the headings even when a section is short — a deliberately empty 'Where we got lucky' is itself a signal.

Two details in that template do real work. First, PagerDuty requires every action item to be filed as a ticket tagged with both sevN and a dated sevN_YYYYMMDD label, so follow-ups are trackable and a stale incident's open items surface in a single query. Second, Google's example tags each action item by type — mitigate, prevent, process, or other — which makes it obvious at a glance whether you actually invested in prevention or only patched the symptom.

The single most common postmortem failure mode is that the document is excellent and nothing changes. Action items are where that is won or lost. Three rules:

• One ticket per item, with an owner and a due date. An action item that lives only in the postmortem prose is a wish, not a task.
• Tag by type (mitigate / prevent / process / other). If every item is 'mitigate', you have not prevented the next occurrence.
• Tag with the incident (sevN_YYYYMMDD) so you can audit completion weeks later and so the prevention backlog is visible to leadership.

For the upstream decisions — what severity to assign and how fast to respond before you ever reach the write-up — see our 15-minute triage playbook and the severity vs priority framework.

Mapping the real example onto the template makes the abstract sections concrete:

Mapping Google SRE's published Shakespeare example onto the template sections shows what good looks like in practice. Note the quantified impact and the typed action items:

The lesson is not the sonnet. It is that a credible postmortem puts a number on impact (66 minutes, 1.21B queries), names multiple contributing factors, and ties every action item to an owner and a ticket. If your draft has none of those three, it is a story, not a postmortem.

The owner-driven drafting workflow matters more than the exact SLA numbers. A review meeting that starts from a blank page degenerates into a group writing exercise — slow, unfocused, and prone to the loudest voice. A review meeting that starts from a complete draft is a quality check: correct the timeline, challenge the contributing factors, sharpen the action items, done. PagerDuty's step-by-step guidance puts timeline reconstruction and analysis before the meeting for exactly this reason.

The expensive, error-prone part of the owner's job is reconstruction: stitching a timeline from logs, recalling what was on screen, finding the failed network call. That is precisely the part grounded in artifacts an agent can read. BugMojo's browser extension captures the rrweb DOM replay, console logs, and network requests for an error at the moment it happens; its MCP server exposes those to an agent. So instead of reconstructing the timeline from memory, the agent reconstructs it from the actual recording and pre-fills the template's Timeline and Contributing Factors sections.

The honest boundary, which the generic 'AI writes your postmortem' pages skip: the agent drafts, the human owns. Deciding which contributing factor matters most, keeping the language blameless, and committing the team to prevention work are judgment calls. The agent's value is removing the blank page and grounding the draft in first-hand evidence — not making the calls.

• Naming a single root cause. Real outages have several. One cause and one fix usually means you stopped asking too early.
• Blame leaking in. 'Why did you deploy on Friday' is a blame question. 'What in the system allowed an unreviewed Friday deploy' is a postmortem question.
• Action items with no ticket. Prose-only items rot. One ticket, one owner, one due date, tagged to the incident.
• Skipping the postmortem because impact was small. A monitoring miss with tiny impact is still a defect — the missing alert is the whole point.
• Drafting in the meeting. The owner drafts first; the group reviews. A blank page in a room of ten is the slowest way to write anything.

• Paste the template into your incident tool and hardcode the five SRE triggers into your 'does this need a postmortem?' check.
• Add the SLAs to your runbook: SEV-1 review in 3 calendar days, SEV-2 in 5 business days, owner named on the incident call.
• Capture replay + console + network in production so the timeline reconstructs from evidence, not memory — then let an agent pre-draft via MCP. Read the upstream 15-minute triage playbook for the steps before the write-up.