How do you reconstruct the timeline of an incident for its postmortem, and which timestamps in that timeline matter most?

## Why the timeline is the load-bearing section Every other part of a postmortem is an interpretation. The timeline is supposed to be the record. If it is wrong, the analysis built on it is wrong in ways nobody can see later, and the postmortem becomes a story rather than evidence. It is also the only section that produces numbers, and the numbers are what make the findings arguable rather than rhetorical. ## Sources, in rough order of trustworthiness 1. **Change and deploy records.** Exact, machine-generated, and usually the closest thing to a trigger timestamp. 2. **Alerting history.** When each alert fired, re-fired and resolved. This gives detection time and also shows which alerts fired and were ignored. 3. **The incident chat transcript.** The single highest-value human source, because it is contemporaneous — it captures what people believed *at the time*, before the answer was known. 4. **Metrics and logs.** Re-query them rather than trusting a screenshot; you often find impact began before the alert threshold was crossed. 5. **Ticketing and paging system records.** Page sent, page acknowledged, escalated to secondary. 6. **Human recollection.** Last, and always reconciled against the above. Memory of an incident is reliably compressed and reordered. Normalize everything to UTC as you go. Mixed local time zones and unsynchronized laptop clocks are a routine source of timelines that imply a mitigation happened before the change that caused it. ## The five timestamps that carry the analysis - **Impact start (t0).** When users first experienced degradation — not when you noticed. Found by walking the SLI back until it leaves its normal band. - **Detection (t1).** When monitoring produced a signal, whether or not a human saw it. - **Engagement (t2).** When a human acknowledged and began working. - **First mitigation applied (t3).** The action that actually reduced impact, which is often not the first action attempted. - **Impact end (t4).** When the SLI returned to normal. Recovery of the underlying defect can be much later and is a separate mark. What matters is the intervals, because each one indicts a different system: ``` t1 - t0 time to detect -> monitoring coverage, thresholds, SLI choice t2 - t1 time to engage -> paging, routing, escalation, alert fatigue t3 - t2 time to mitigate -> runbooks, access, tooling, diagnosis difficulty t4 - t3 time to recover -> propagation, cache TTLs, restart and drain time ``` A team that reports only "the incident lasted 74 minutes" cannot tell whether to invest in monitoring or in rollback tooling. A team that reports 22 / 3 / 41 / 8 knows immediately that diagnosis was the expensive part. ## Recording belief, not just action For each significant entry, note what the responders thought was happening. "14:22 — restarted the cache tier, believing the latency was cache eviction" is a far more useful line than "14:22 — restarted the cache tier." Long unexplained gaps are usually not idle time; they are time spent on a hypothesis that turned out to be wrong, and *why it was plausible* is the finding. Frequently the answer is that a dashboard, a misleading alert name, or a runbook pointed there. ## Guarding against hindsight Writing the timeline after you know the answer makes every wrong turn look obviously wrong. Two habits help. First, mark clearly what information was available at each timestamp rather than what was true — the signal that would have identified the cause may not have existed on any dashboard yet. Second, write the timeline before writing the causes section, and resist editing entries to fit the conclusion you later reach. ## Practical mechanics Start the timeline during the incident, not after. A scribe pasting timestamped notes into the incident channel costs almost nothing and saves hours of reconstruction. Anything not captured live must be re-derived from logs that may have already rolled off short retention — which is itself a finding worth writing down. ## In an interview Name the sources, name the intervals, and give one example where separating detect-time from mitigate-time changed the investment decision. That is the answer of someone who has actually written one.