A postmortem that produces a beautifully written timeline and no completed actions has cost a team an afternoon and changed nothing.
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.
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.
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.
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.
A structured review after a failure covering the timeline, customer impact, detection, contributing factors and the actions that follow.
Asking why an action made sense to the person at the time rather than who was at fault. It is a method for getting accurate facts, not a reason to be vague.
Few enough to be completed. Three finished actions beat fifteen listed ones.
Detection time as well as resolution time — the interval before anyone knew is usually the most improvable and the least tracked.
A snagging list records the defects found before handover. Its value is entirely in the timing — the same defect is a five-minute fix before completion and an argument afterwards.
Almost everything that goes wrong at a company event was decidable weeks earlier. A checklist ordered by deadline rather than by category is what turns the last week from firefighting into confirmation.
Most OKRs fail in the writing, not the doing. An objective nobody can picture and key results that are really a task list produce a document reviewed twice and abandoned by week six.