What has to be recorded while an incident is still in progress for the postmortem timeline to be usable, and why can't you just reconstruct it afterwards from the chat log?

## What the timeline is for The postmortem timeline is not a narrative for readers who missed the incident. It is evidence, and it supports two things that cannot be produced any other way. First, the **durations**: how long until anyone knew, how long until a human was engaged, how long until impact stopped. Those numbers drive whether the follow-up work should target detection, response or the failure itself — three completely different investments. Second, the **decision record**: what each responder believed at the moment they acted. Analysis of contributing factors depends entirely on comparing what was reasonable given the information available at the time against what turned out to be true, and that comparison is impossible once the timeline has been reconstructed by people who now know the answer. ## The three kinds of entry Tag every entry as one of: - **Observed** — a fact from a system: a metric value, an alert firing, a log line, a customer report. Include where it came from so it can be checked later. - **Done** — an action taken against production, with who took it. "Restarted the three workers in eu-west-1" is a timeline entry; "maybe we should restart the workers" is not. - **Decided** — a choice between options, with the reason and the information available at the time. This is the highest-value and most frequently missing category. The distinction matters because scrollback flattens all three into undifferentiated text. Six weeks later nobody can tell whether "looks like the cache is cold" was a confirmed measurement or a guess someone typed while scrolling a dashboard — and in most postmortems that read badly, a guess had quietly become the accepted account of events. ## The four anchors Always pin down: when the failure actually began (often earlier than detection, established later from data), when it was detected, when a human acknowledged and declared, when mitigation was applied, and when impact ended and was confirmed ended. These give the durations that make incidents comparable across a quarter, and they are the ones people argue about afterwards if nobody wrote them down at the time. ## Why chat scrollback is not a timeline Every one of these is a real, repeated failure: - **Message time is not event time.** "Rolled back" typed at 14:36 might describe a rollback started at 14:29 and finished at 14:34. Duration arithmetic built on message timestamps is simply wrong. - **The bridge is silent.** The most consequential decisions in a fast incident are made on a voice call. If nobody types "decision: failing over to the secondary, accepting up to 30 seconds of writes lost", that decision never existed as far as the record is concerned. - **Side channels.** Direct messages, a vendor's support portal, another team's channel and someone's terminal history each hold pieces the incident channel never saw. - **Evidence rots.** Dashboard links resolve to a relative time range and show something different next week; short-retention logs age out; the deployment that caused it gets superseded. Screenshot and paste the numbers into the log while they exist. - **Memory is reconstructive.** People genuinely and honestly remember having suspected the true cause earlier than they did. This is not dishonesty; it is how memory works, and it is exactly the corruption that makes a late-built timeline useless for judging whether the response was reasonable. ## Keeping it cheap The honest tension is that every minute spent recording is a minute not spent fixing, so capture has to be nearly free. What works in practice: someone who is not on the keyboard owns the log (in a structured response this is a dedicated scribe); the incident channel is the single working surface so mentions can be marked into the timeline with a reaction or a bot command; deployment, rollback and configuration systems emit their own timestamped events into the channel automatically so the highest-value entries need no human; and after mitigation, while everyone is still on the call, the group spends ten minutes filling gaps before dispersing. That last habit — a short timeline sweep immediately after impact ends — recovers more than any attempt a week later. ## The trade-off to state out loud You can run an incident with nobody recording and go faster in the first twenty minutes. What you buy with that speed is a postmortem that argues about what happened instead of what to change, and follow-up work aimed at the wrong stage of the response. The cost of live capture is one person's attention; the cost of skipping it lands weeks later on everyone.