Incident postmortem: the actions are the output, not the document

An incident postmortem is the structured review held after a service failure: what happened, in what order, what the impact was, what contributed to it, and what will be done differently. It is deliberately separated from the incident itself, because the priority during an outage is restoration and the priority afterwards is understanding.

The measure of a postmortem programme is not the quality of the write-ups. It is what fraction of the actions they produce are actually completed. Organisations reliably generate documents and reliably fail to close the follow-ups, which converts an improvement process into a documentation habit.

What an incident postmortem covers

• A timeline with timestamps: when the problem started, when it was detected, when it was acknowledged, what was tried, when it was resolved.
• Impact in customer terms — who was affected, for how long, what they could not do — rather than in infrastructure terms.
• Detection: how you found out. If a customer told you, that is a finding in itself.
• Contributing factors, plural. Real incidents have several, and the search for a single root cause usually stops at the most visible one.
• What went well, which is not decoration — the mitigations that worked are worth strengthening.
• Action items with an owner and a date, distinguishing what prevents recurrence from what reduces impact next time.

Blameless means factual, not vague

A blameless postmortem asks why an action made sense to the person taking it, given what they knew at that moment, instead of asking who was at fault. That is a discipline for getting accurate information — people describe their reasoning honestly when it is not being used against them — and it is often misread as an instruction to be imprecise. Naming that a deploy proceeded without the usual check is a fact and belongs in the document; concluding that somebody was careless does not.

Cap the action list. A postmortem generating fifteen items produces fifteen items nobody does. Three that get finished beat fifteen that decorate a document, and choosing the three is the real work of the meeting.

Detection time is the number to watch

Across a series of incidents, the interval between the problem starting and somebody knowing about it is usually the most improvable metric and the one least often tracked. Resolution time gets attention because it is visible; detection time is where the hours hide. Recording both consistently gives a programme something to measure other than incident count, which is a poor proxy for anything.

Deploying anything into production is itself a change. A change control process records what is being changed, who approved it and how it will be reversed, which is what turns an emergency fix into a traceable decision.

Tracking the actions to closure

Actions belong where the team’s other work lives, with an owner and a date, not in the postmortem document where they are invisible a week later. Ettex Board tracks them to closure alongside normal work so they compete for attention honestly, Ettex Docs holds the postmortems themselves with version history, and Ettex Records keeps the series so patterns across incidents are visible — the same contributing factor appearing three times is the finding no single review produces. The procedures updated as a result sit with the incident response plan.

To be clear: this is documents and task tracking, not an incident management platform. Paging, status pages and incident timelines belong in dedicated tooling; what this covers is the review and, more importantly, what happens to its output.