Incident Post-Mortem
Run a blameless post-mortem that finds the real systemic cause.
A blameless post-mortem with root causes and concrete preventions.
Post-mortems fail in two directions: they find a scapegoat, or they produce a wall of action items nobody does. The Reliability Engineer reconstructs the timeline as systems saw it, the Systems Thinker pushes past the trigger to the conditions that made the trigger matter, and the Pre-Mortem Analyst asks which near-misses foreshadowed this. The Data Skeptic separates real prevention from theatre, the Software Architect owns the blast-radius question, and the People Lead keeps it blameless — because the moment blame enters, information stops.
Help us run a blameless post-mortem on an incident and find the systemic causes, not a scapegoat. THE INCIDENT: [what happened, the timeline, the impact on users and the business] DETECTION & RESPONSE: [how we found out, how long to detect/mitigate/resolve] WHAT WE THINK WENT WRONG: [the current theory] Debate: 1. The real root cause(s) — push past the first explanation to the systemic one (the five whys). 2. Why detection took as long as it did, and what signal we were missing. 3. Why the blast radius was as large as it was, and how to contain it next time. 4. The contributing factors — process, tooling, ownership, on-call load — not just the trigger. 5. Which proposed fixes are real prevention versus which are theatre. FINAL SYNTHESIS: - A blameless statement of the root cause(s). - A timeline of what would have caught or contained it earlier. - A ranked list of preventions and detection improvements, each with an owner and the risk it removes.
An illustrative excerpt for a hypothetical brief of this type: A payments service was down for three hours after a routine database migration locked a critical table during peak traffic; the engineer who ran it had followed the documented runbook. Every real run is generated fresh from your specifics, debated across rounds, and audited before the verdict.
Timeline first, blame never: the migration ran at 14:00 — peak traffic — because the runbook does not specify a window. Lock contention cascaded in four minutes, but the page fired at 14:22, which means eighteen minutes of the outage were a detection gap, not a migration problem. Two separate findings already, and neither is a person.
The five-whys bottoms out in an incentive, as usual: migrations are the only change class that skips staging because the staging database is a fraction of production size, so lock behaviour is invisible before production. The runbook is a symptom. The system made this failure eventual — this engineer merely collected it.
On the proposed fixes: “add a migration checklist item” is theatre — the runbook was followed perfectly, so more runbook changes nothing. Production-scale lock testing on a database clone and an automatic migration window guard are mechanical preventions; those two would each have stopped this outage. Fund the mechanical ones, skip the ceremonial ones.
One process note for the write-up: the engineer self-reported within minutes and that is why the timeline is trustworthy. If this post-mortem generates anything that reads as consequences for them, the next incident gets discovered twenty minutes later than this one did. The report should name the fast self-report as the thing that worked.
Prefer drop-and-go? Use the Incident Post-Mortem tool — team pre-seated, included with Plus.
What should I paste in — how detailed must the timeline be?
What happened in order with rough timestamps, the user impact, how it was detected and resolved, and your current theory of the cause. Gaps are fine and are themselves findings — “we don’t know when it started” is a monitoring gap the synthesis will flag with the rest.
How does this stay blameless when someone clearly made a mistake?
The method assumes a competent person acting reasonably inside the system as it exists — then asks what about the system made the mistake possible, invisible or damaging. In the example above, the engineer followed the runbook exactly; the findings are all structural. That reframe is the entire value of the format.
We already do post-mortems — why put one through a council?
Internal post-mortems inherit internal politics: the infrastructure team writes infrastructure findings, and the first plausible root cause ends the digging. Independent personas have no turf, so the five-whys goes past the comfortable stopping point — and the Data Skeptic culls the action items that exist to look thorough rather than to prevent recurrence.