What is Postmortem?
Also called post-incident review, retrospective.
A postmortem is a structured written review conducted after an incident, recording what happened, the timeline, the contributing causes, the impact, and the specific changes that will reduce recurrence. Its output is a durable document and a set of owned action items, not a verdict on individual performance.
The blameless convention is the practice's central discipline. Reviews are framed around why an action seemed reasonable given the information available at the time, not who erred. This is instrumental rather than sentimental: teams that assign blame lose access to the accurate accounts they need, because participants become careful rather than candid, and the most informative details go unrecorded.
Cause analysis benefits from resisting the singular. Most incidents in production systems require several conditions to coincide: a latent defect, a monitoring gap that delayed detection, and a control that behaved as configured but not as intended. Stopping at the first plausible cause typically produces a narrow fix for the specific trigger while the conditions that let it become an incident remain in place.
Action items are where postmortems succeed or fail. Items need a named owner, a due date, and a tracked location, and the set should be small enough to actually complete. A backlog of unfinished postmortem items across several reviews is a reliable indicator that the practice has become ceremonial, and it is worth measuring completion explicitly rather than assuming it.
Postmortems are appropriate for AI-specific failures that never appear in infrastructure metrics: an agent taking an unintended action, a prompt change that degraded output quality across a tenant, a retrieval regression that produced confidently wrong answers. These require different evidence, notably captured run traces and sampled outputs from the affected window, which is a reason to retain that data long enough to review after the fact.
Key points
- Structured record of timeline, causes, impact, and owned actions
- Blameless framing is what preserves access to accurate accounts
- Most incidents have several contributing conditions, not one cause
- Action items need owners, dates, and tracked completion
- Quality and agent-behavior failures deserve postmortems too
In practice
After an agent misfiled 200 records, the review reconstructs the timeline from run traces. Three conditions combined: a schema field was renamed without updating the tool description, the evaluation set contained no example using that field, and the write path had no per-run volume cap. Three items follow, each owned: a contract test on tool schemas, added coverage, and a cap that pauses a run exceeding fifty writes.