What makes a useful incident postmortem?

Direct answer

What a strong answer covers

How it works

A postmortem exists to make the next incident less likely or shorter, not to assign fault. It states user impact in numbers and a precise timeline from first signal to resolution. It describes the contributing conditions, both technical and organisational, such as a missing alert, an untested rollback, or a change review that was skipped under deadline, with evidence for each. It analyses detection and response separately: how long until someone knew, how long until the right person acted, what slowed mitigation. It closes with a small number of actions, each with an owner and a date, tracked to completion, and it is shared widely so other teams learn.

Example

After a 40-minute checkout outage, the postmortem recorded 12,000 affected sessions, a timeline showing 18 minutes from first errors to the page because the alert was on a 15-minute window, and a rollback that took 15 minutes because the runbook was stale. Actions: a burn-rate alert with a 2-minute window, a quarterly rollback drill, and a change to deploy config through the same pipeline as code. All three were done within a month and reported back.

Common mistakes

• Naming an individual as the cause and stopping the analysis there.
• Producing twenty action items nobody owns.
• Writing the document and never checking whether the actions were completed.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.