How Soon After an Incident Should the Postmortem Happen? The Memory Window
Capture the facts within 24 to 48 hours and hold the discussion within a week. Those are two different activities with opposite requirements, and running them as one event is why postmortems tend to be either exhausted and shallow or thorough and inaccurate. The details decay fast, so capture has to be quick. The analysis needs rested people who have had time to think, so it should not be immediate.
This article covers why memory decay sets the capture deadline, why analysis benefits from distance, how to split the two without adding process overhead, and what genuinely justifies delay. It also covers the point past which a postmortem stops being worth holding.
Why the capture window is short
Incident detail decays quickly and unevenly. Within a day or two, most responders can still tell you what they did and in what order. Within a week, the sequence blurs, the reasoning behind decisions is largely gone, and what remains is a tidied narrative in which the eventual cause seems more obvious than it was.
That last part is the real cost, and it is why the deadline matters more than it seems. The most valuable content of a postmortem is usually not what broke. It is why the response took the shape it did: which signal was misleading, why the first hypothesis was reasonable and wrong, what somebody checked and discarded. That reasoning is the first thing to disappear, because once you know the answer it becomes genuinely difficult to reconstruct why you did not know it. A postmortem written a fortnight later records the cause accurately and the response as a straight line, and it teaches almost nothing.
Chat transcripts help with sequence but not reasoning. The channel shows that someone restarted a service at 02:14. It rarely shows why they thought that would help. Our guide to incident postmortems covers what the document should contain once you have the material.
Why the analysis should not be immediate
The argument for holding the full review the next morning is that memory is freshest. It is a real argument and it is outweighed by two others.
People are tired. An incident that ran until three in the morning leaves responders who slept badly and are not in a state to think carefully about systemic causes. A review conducted in that state produces shallow action items, typically an alert to add and a runbook to write, and misses the harder questions about why the failure was possible.
And the emotional proximity is wrong. Immediately after a bad incident, whoever pushed the change that triggered it is at their most defensive, and everyone else is at their most certain about what should have been obvious. Blameless postmortems are much easier to run a few days later, when the outage has stopped feeling like an accusation. That is not a soft consideration. Defensiveness in the room is the main mechanism by which contributing factors go unmentioned.
The memory window, and how to split the two
Call this the memory window: facts within 48 hours, analysis within a week. The split costs almost nothing and fixes both problems.
The capture step is short. Within a day or two of resolution, whoever coordinated the incident writes down the timeline, working from the war room transcript where there was one, what each person observed and tried, what was ruled out, what the customer impact was, and the open questions. Fifteen to thirty minutes of writing, ideally with the responders adding their own recollections directly. This is not the postmortem. It is the raw material, and it explicitly does not need conclusions.
The analysis step is the meeting, held within a week while the incident still matters and after everyone has slept. It works from the captured document rather than from memory, which changes the character of the discussion completely: instead of reconstructing what happened, the room is examining an agreed record and asking why it was possible.
A practical detail that makes this work: capture the open questions at the time, not just the facts. Things nobody knew during the incident are the most valuable items on the agenda, and they are also the things most likely to be quietly resolved and forgotten before the meeting.
When delay is justified, and when it is not
Delay is reasonable when the incident is not actually over, when a key participant is unavailable and their account is essential, or when you are still gathering data that the analysis depends on. In those cases, do the capture step anyway and delay only the meeting.
Delay is not justified because everyone is busy. This is the reason postmortems are actually delayed, and the cost is invisible, which is why it keeps happening. A postmortem repeatedly pushed for two months does not produce a worse document than one held in a week. It produces no document, and the incident's lessons live only in the memories of the people who were there, until those people change teams.
There is a point past which the exercise stops paying. Beyond roughly a month, unless the incident was severe enough that the analysis is required regardless, you will get a factual summary and little insight. If you find yourself there, the honest move is usually to write a short factual record, extract whatever action items are still obvious, and put the effort into holding the next one on time.
Severity should adjust the shape rather than the deadline. A major customer-facing outage warrants a full review with a wide audience. A minor incident with a known cause warrants a paragraph in the handoff document and a ticket. What should not vary is that something gets written while people still remember.
Common mistakes in scheduling a postmortem
Holding the full review the morning after a night incident. Exhausted responders produce shallow analysis and defensive discussion. Capture the facts immediately, hold the discussion once people have slept.
Waiting until everyone is free. Calendars never open up, and the delay compounds. Capture within 48 hours with whoever is available and schedule the meeting for whenever the majority can attend within the week.
Relying on the chat transcript as the record. It preserves sequence but not reasoning, and reasoning is the part that decays and the part worth having.
Recording only what happened, not what was believed. The dead ends and wrong hypotheses are where the improvements live. A timeline of correct actions describes a response nobody actually had.
Treating a missed deadline as a reason to skip it entirely. A late, short factual record is worth considerably more than nothing, and it keeps the practice alive for the next incident.
FAQ
How soon after an incident should the postmortem happen?
Capture the facts within 24 to 48 hours and hold the discussion within a week. The capture deadline is driven by memory decay, particularly of the reasoning behind decisions, and the discussion benefits from people having slept and gained some distance.
Should the postmortem be held the next day?
Usually not for the full review. Responders coming off a night incident are tired and the discussion tends to be defensive. Write the timeline the next day and hold the analysis a few days later.
How long is too long to wait for a postmortem?
Beyond about a month you will get a factual summary and little insight, because the reasoning behind in-the-moment decisions has gone. If you reach that point, write a brief record, capture the obvious action items, and focus on holding the next one on time.
Do all incidents need a postmortem?
No. Severity should determine the depth, not whether anything is written. A major customer-facing outage warrants a full review; a minor incident with a known cause warrants a short note and a ticket. Something should be written down either way.
Closing thought
The reason postmortem timing is worth being deliberate about is that the two things you want from the exercise decay in opposite directions. Accuracy is highest immediately and falls away fast. Insight is lowest immediately, when everyone is tired and defensive, and improves for several days before the incident stops feeling relevant. There is no single moment that optimises both, which is precisely why the answer is to stop looking for one and do them separately.
Accurate timelines are much easier when the detection time is not a matter of recollection. Odown checks from seventeen global locations at intervals down to one minute on every plan, which gives a postmortem an independent record of when the failure became externally visible and from where, rather than a first data point that reads customer emailed support.
