Post Mortem

Post-Mortem (Blameless Incident Review)

Overview

A post-mortem is a structured, blameless review held after an incident, outage, regression, missed launch, or failed experiment. The goal is not to assign fault but to learn how the system (people, process, code, and organization) produced the outcome, and to commit to durable changes that reduce the chance of recurrence.

This skill operationalizes the Google SRE blameless post-mortem template, the Etsy "morgue" tradition, John Allspaw's "How Complex Systems Fail" reading, Charles Perrow's Normal Accident Theory, and Sidney Dekker's Field Guide to Understanding "Human Error". Where the companion discovery/pre-mortem/ skill imagines failure before it happens, post-mortem learns from failure that already did.

Core Capabilities

• Severity classification — Sev 0-4 + near-miss thresholds, with post-mortem requirement and SLA per level
• Blameless facilitation — five ground rules, the Dekker New View, hindsight/counterfactual removal, the Allspaw test
• 10-section authoring — header → summary → impact → timeline → what went well/wrong → factors → RCA → actions → lessons
• Root-cause analysis — 5 Whys for clear chains, Causal Tree for multi-factor Sev 0/1/2; root-cause vs contributing-factor
• Action-item discipline — single owner, real ticket, testable acceptance criteria, recurring completion audit
• Distribution & archive — audience-appropriate formats; searchable, service-tagged archive

When to Use

• Sev 1 / Sev 2 incident — customer-facing outage, data loss, security event, payments failure, or significant regression.
• Sev 3 with novelty — worth a post-mortem if it surfaced a failure class the team has not seen before.
• Missed launch or rolled-back release — the launch itself is the incident.
• Failed experiment with a negative business outcome — e.g. a pricing test that depressed revenue.
• Customer escalation — an exec customer call where the product was the proximate cause.
• Near miss — the deploy that "almost" took the site down; some of the highest-leverage learning a team gets.

If the incident is below the severity threshold and the team has seen the same class of failure recently, document the recurrence in the existing post-mortem rather than producing a new one.

Clarify First

Before authoring the post-mortem, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Severity level — Sev 0-4 / near-miss sets the template depth, the SLA window, and whether 5 Whys or a Causal Tree is required
• Incident timeline / chat transcript — the source for the Timeline and Impact sections; without it the reconstruction is guesswork
• Customer / business impact — scope, duration, and who was affected drives both the Impact section and the severity itself
• Root-cause method — 5 Whys for a clear single chain vs Causal Tree for multi-factor Sev 0/1/2; drives the RCA section

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Quick Start

1. At incident close, the incident commander assigns an author who opens assets/post_mortem_template.md.
2. Scaffold Header, Summary, Impact, and Timeline from the incident chat transcript.
3. Within the SLA window (Sev 1: 5 business days, Sev 2: 7), draft the remaining sections, run the chosen root-cause method, and hold a 60-90 min blameless review.
4. Apply the Allspaw test, file every action item as a real ticket with an owner and due date, then publish to the searchable archive.

The blameless principles, severity thresholds, full template, workflow, and root-cause methods all live in the references below.