How soon after an incident should a postmortem be drafted and reviewed, and who should write it?

## Why the clock matters Everything a postmortem needs decays. Human recollection of *why* a decision looked correct at 03:00 is gone within about a week, and what remains is a tidied-up reconstruction that makes everyone look more rational than they were — which is exactly the information you least want to lose. Chat scrollback gets buried, dashboards roll off high-resolution retention into coarser rollups, and short-lived debug logs expire. A postmortem written three weeks later is frequently written *from the logs that survived*, which quietly biases the account toward whatever happened to be retained. The second decay is organizational. The impact of an outage is loudest in the days after it. That is when a P1 action item can win against roadmap work. Three weeks on, the outage is a story people tell, the team has new commitments, and the same item now has to displace something already promised. Speed of publication is, in practice, a lever on whether the fixes get funded at all. ## Assign the author during the incident The single most effective mechanic here is naming the postmortem owner while the incident is still open — the incident commander either takes it or names someone. An unassigned postmortem after an exhausting night is an orphan, and orphans are late. Naming it early also means the author starts collecting timestamps, screenshots and graph links *while they are still on screen*, which converts the write-up from an archaeology exercise into a transcription. A reasonable house standard: draft within three business days for a major incident, review within a week, published and closed within two. Numbers vary; having *a* number and tracking against it is what matters, because "soon" is not a deadline. ## Who writes it The responders. They have the only copy of the reasoning — what they believed, what signal they were looking at, what they ruled out and why. Handing the write-up to an uninvolved engineer produces a document that is accurate about events and empty about decisions, and it also removes the learning from the people best placed to use it. The common counter-argument is that responders will write self-servingly. In practice that risk is handled by the review, not by changing the author, and a document written by someone who was not there is not more objective — it is just less informed. ## Who reviews it A good review has three roles present: 1. **The responders**, who correct the timeline. 2. **A senior engineer familiar with the system**, who challenges whether the contributing factors are actually understood and whether the action items address them. 3. **At least one person with no involvement in the incident**, who is the real test of whether the document is comprehensible to the audience it was written for. If they cannot follow it, neither will the engineer who finds it in the repository in a year. Some organizations add a rotating reviewer or a small review group for higher-severity incidents specifically to keep quality consistent across teams. ## What the review meeting is for — and what it is not It is not a re-telling of the incident. Everyone reads the document first; if they have not, the meeting is worthless and should be rescheduled. The meeting exists to resolve disagreements about the timeline, to challenge weak action items, and — most importantly — to leave with every committed item carrying a named owner and a date. "We'll sort out owners after" is the sentence that produces an unowned backlog; the meeting is the moment when the room's attention makes assignment cheap, and that leverage is not recoverable later. A meeting that has become a twenty-person status readout has lost its function. Cut it to the people who can actually change something, or make the review asynchronous with a comment deadline and reserve the synchronous slot for the incidents where genuine disagreement exists. ## Not every incident needs the same weight Coupling postmortem depth to severity keeps the practice sustainable: a full document with a review meeting for the incidents that hurt customers, a short written record for the smaller ones, and nothing at all for routine noise. Demanding a full postmortem for every page produces ritual documents nobody reads and crowds out depth on the incidents that deserve it.