Blameless Postmortems

The Google SRE Book postmortem template, what "blameless" really means, and how to extract action items that ship.

Overview

Systems, not individuals

Blameless postmortems are the SRE Book's most-quoted contribution to industry practice. If humans fear blame, they hide failures and mitigate without disclosure, and the organization can't learn. Blameless culture is a prerequisite for honest incident analysis.

"Blameless" doesn't mean "no consequences." It means asking "how did our system, processes and tools make this failure possible?" rather than "who pushed the bad code?" Action items are systemic fixes, not "Bob will be more careful."

The postmortem template (SRE Book Ch 15)

1 — Title — Concise and searchable: "Checkout 50% error rate for 23 minutes due to deploy v3.2.1"
2 — Authors — Typically the IC and Ops Lead
3 — Status — Draft / In Review / Final
4 — Summary — 1-3 sentences: what broke, when, who was affected, how it was fixed
5 — Impact — Quantified: users affected, revenue, SLO budget consumed, customer SLA implications
6 — Detection — Who noticed first (monitoring, customer, engineer) and the gap between start and detection
7 — Root Causes — Often several contributing factors; use Five Whys. Never stop at "user error": ask why the system permitted it
8 — Resolution — The mitigation that stopped the bleeding
9 — Lessons Learned — What went well, what went poorly, where we got lucky
10 — Timeline — Minute by minute, timestamped from chat logs, alert history and screenshots; T-zero is detection (sometimes start)
11 — Action Items — Specific, owned, dated: ticket, owner, target date, priority
12 — Supporting Information — Dashboards, logs, charts, screenshots, related postmortems

> [!TIP] "Where we got lucky" is the underrated section. "If the on-call had been at lunch, we'd have been down for an hour" names a systemic vulnerability masked by good fortune.

Publishing discipline

Time-bound — Draft within 5 business days, final within 10; details decay fast
Cross-team review — Stakeholders read the draft and add missed perspectives
Searchable — Lives in a wiki, queryable by service, date and root cause; the on-call ten years from now should find it
Linked from runbooks — Runbooks for a known failure pattern link the seminal postmortem

> [!IMPORTANT] The 1:1 rule: every incident gets one postmortem, even small ones. Writing teaches more than fixing.

The threshold

Google publishes full postmortems internally for incidents over a threshold: customer impact > X minutes, revenue impact > $X, a security event, or a novel failure mode. Below it, a lightweight "incident note" is enough.

Key concepts

Blameless: Focus on systems and processes, not on the person who pushed the change. Action items are systemic fixes.
Five Whys: Iterative why-chain to find root cause. Each "why" peels back another layer; usually 5 is enough to reach systemic factors.
Where we got lucky: Underrated postmortem section. The vulnerabilities that didn't bite this time but could have. Often the most learning.
Action item categorization: Prevention / Detection / Mitigation. Categorizes investments and prevents over-prevention bias.
Time-bound publication: Draft within 5 business days; final within 10. Detail decay is fast.
Postmortem index: Searchable repository of past postmortems. Ten years later, the next on-call should find it.

When to use it

After every meaningful incident — within 5 business days, draft published
Onboarding new SREs — read 5-10 postmortems from the team's history
Before major migrations — review postmortems from similar past migrations
Quarterly retrospectives — pattern-match across postmortems for systemic issues

Interview questions

What does "blameless" really mean in a postmortem?
Walk me through the structure of a good postmortem.
How do you make sure action items actually ship?
When is a postmortem NOT needed?