Incident Timeline

Why it exists

During a stressful incident, memory is unreliable and people compress or reorder events afterward. A timeline exists to capture an accurate, objective sequence as close to real time as possible, so the later analysis is built on facts rather than reconstructed impressions.

The mental model

Picture a single column of timestamped entries that interleaves machine events and human actions: an alert fired at one time, an engineer acknowledged it minutes later, a rollback started, a metric recovered. Each entry says when it happened and, ideally, what the responder knew and believed at that moment, not what we know in hindsight.

How it works

Entries are collected from multiple sources: alerting and monitoring systems, deploy and change logs, chat transcripts from the incident channel, and responders' own notes. They are merged into one chronological record with consistent timestamps. Key checkpoints are usually marked, such as when the issue began, when it was detected, when it was acknowledged, when mitigation began, and when service was restored, which lets you compute durations between phases.

When it matters

The timeline is the backbone of the postmortem. It matters most when you want to improve detection and response rather than just fix the immediate bug: long gaps between onset and detection point to monitoring gaps, gaps between detection and mitigation point to process or tooling problems. It also matters for keeping the analysis blameless, because it records context and constraints, not just outcomes.

A concrete example

A timeline shows a bad deploy went out at 14:02, errors spiked at 14:03, but no alert fired until 14:41 and an engineer acknowledged at 14:45, with a rollback restoring service by 14:52. The 38-minute detection gap, visible only because the timeline is precise, becomes the headline action item: add an alert on the metric that was already degrading.