Postmortem

A postmortem, also called an incident review, is a document and meeting that analyzes a failure after it has been resolved, such as an outage, a data loss, or a security breach. It records the timeline of events, the impact on users, the root causes and contributing factors, and a list of action items with owners. The goal is to learn from the incident, not to assign blame.

Most teams follow a blameless approach: the review assumes that people acted reasonably with the information they had, and it asks why the system made the mistake easy rather than who made it. A typical postmortem is written within a few days, while memories are fresh, using chat history, dashboards, and alerts to rebuild a precise timeline. Techniques such as asking why repeatedly, often called the five whys, help dig past the first obvious cause, like a bad configuration change, to deeper ones, like the lack of automated checks before that change went live.

The practice is borrowed from medicine and aviation, where investigators study every accident to improve safety for everyone, not to punish the pilot. In software, postmortems are a core part of site reliability engineering and incident management, and many companies publish them so customers can see what went wrong. Their value depends on the follow-up: action items such as adding an alert, a test, or a safer deployment step must actually be tracked and completed.

A postmortem is often confused with a retrospective. A retrospective is a routine meeting at the end of every sprint about how the team works in general, while a postmortem is triggered by a specific incident and focuses on the technical and organizational causes of that failure. Both aim at improvement, but a postmortem produces a detailed written record of one event.