Blameless Postmortem
/ˈbleɪm.ləs ˈpoʊst.mɔːr.təm/ · Noun · Development · Origin: 2004
Definitions
A structured review conducted after an incident that focuses on understanding systemic causes and improving processes, explicitly avoiding individual blame — based on the principle that humans make mistakes and systems should be designed to be resilient to them.
In plain English: After something goes wrong, the team writes up what happened without pointing fingers at anyone. The goal is to fix the system so it doesn't happen again, not to punish someone.
Example: "The blameless postmortem revealed that three separate monitoring gaps lined up perfectly — nobody was at fault, but we added alerts for all three."
Origin Story
The cultural practice that made it safe to admit you broke production
The **blameless postmortem** was popularized by John Allspaw and others at Etsy around 2012, drawing on ideas from **Sidney Dekker's** work on just culture in aviation safety. The principle: focus on what happened and why, not on who to punish.
Traditional incident reviews asked "who screwed up?" Blameless postmortems ask "what conditions allowed this failure to occur?" The human who pushed the bad deploy is the last line of defense, not the root cause. Systems should prevent humans from causing outages.
Google's SRE book (2016) codified blameless postmortems as standard practice. The format -- timeline, impact, root cause, action items -- became universal. The hardest part isn't the template; it's building a culture where people genuinely feel safe admitting mistakes.
Coined by: John Allspaw / Etsy (popularized), Sidney Dekker (just culture theory)
Context: Etsy, ~2012; Google SRE book, 2016
Fun fact: Allspaw's 2009 Velocity talk ' 10+ Deploys Per Day' (with Paul Hammond) was a watershed moment for DevOps. His later work on blameless postmortems drew from aviation's Crew Resource Management, which was developed after analyzing cockpit voice recorders from crashes.