Postmortem

Origin & evolution

The blameless idea was imported from safety science, not invented in software. James Reason's work on human error and Sidney Dekker's writing on Just Culture framed a hard finding from aviation and medicine: punishing the individual at the sharp end leaves the latent system conditions untouched, so the next person inherits the same trap. Dekker named the punitive reflex the Bad Apple Theory and showed it does not make complex systems safer.

John Allspaw carried that thinking into engineering. In 2012, as CTO of Etsy, he published Blameless PostMortems and a Just Culture on Etsy's engineering blog, arguing that engineers who feel safe to give a detailed account of what they saw and did are the organisation's best source of truth about how the system actually behaves. Etsy backed it with a tool, Morgue, for recording these reviews. Google's Site Reliability Engineering book then codified the practice and the template, and the industry followed.

The debate since has been about accountability. Blameless does not mean consequence-free; the refinement most teams reach is that you separate the account of the failure, which must be safe and honest, from any question of competence, which belongs to a different conversation. The phrase "blameless, not accountability-free" captures where the field landed.

How it works in practice

After a Sev2 checkout outage, the incident commander schedules a postmortem within two days while memory is fresh. The author builds a minute-by-minute timeline from chat logs and graphs, then writes the analysis in language that names systems and not people: the deploy pipeline had no automated canary, so a bad config reached 100 percent of traffic in ninety seconds.

The document lists contributing factors rather than a single culprit, and ends with dated, owned action items: add a canary stage, alert on config diff size, document the rollback in a runbook📘RunbookDevOps & PlatformA runbook for incident responseView reference →. It is shared widely, because the point of writing it down is that the team three doors over learns the lesson without living the outage. A year later the canary action item is the reason a similar bad config is caught at 1 percent.

Postmortem vs. its neighbours

• Incident is the live event. The postmortem is the reflection afterwards. The incident is measured in minutes of disruption; the postmortem is measured in lessons extracted.
• Root cause🪝Root CauseEngineeringAn identified root cause of an issueView reference → is a conclusion the postmortem reaches, the condition the analysis identifies. The postmortem is the whole document and process; the root cause is one of its outputs. Mature postmortems resist naming a single root cause, preferring a set of contributing factors.
• Retrospective🪞RetrospectiveTeam & OrganisationA team retrospectiveView reference → is a recurring team ritual reflecting on a sprint or a period of work. A postmortem is triggered by a specific failure. One is cadence-driven and broad; the other is event-driven and forensic.

In the graph

In the Unified Product Graph, postmortem🩻PostmortemDevOps & PlatformA post-incident review is a leaf in the Operations and Quality region, reached from the anchor incident🚨IncidentDevOps & PlatformA production incidentView reference → through incident_analysed_in_postmortemIncidentanalysed inPostmortemhierarchy and incident_triggers_postmortemIncidenttriggersPostmortemcross-domain. Its own causal edges are what make it valuable: postmortem_identifies_root_causePostmortemidentifiesRoot Causecausal connects the analysis to the condition it found, and postmortem_produces_runbookPostmortemproducesRunbookcausal connects it to the operational change it generated. That second edge is the learning🧠LearningValidationAn insight gained from an experimentView reference → loop made structural. A postmortem that produces no runbook and identifies no root cause is visibly a document that changed nothing.