A timeline is evidence before it is a story
During an incident, messages arrive from monitoring tools, calls, chat channels, ticket systems, and individual notes. A timeline brings those fragments into chronological order. Its first purpose is not to make the incident sound tidy. It is to preserve what was known, when it was known, and what action followed.
A good incident timeline preserves uncertainty instead of polishing it away.
Write each entry as time, fact, action, outcome
A practical entry might say: 09:14 — monitoring detected elevated error rate; on-call engineer acknowledged the alert; investigation started. Avoid vague lines such as system had issues in the morning. Precise timestamps and observable events make the timeline useful for later analysis.
Separate observation from interpretation
If a root cause is not yet confirmed, label it as a hypothesis. Do not retroactively write early assumptions as facts simply because the final diagnosis later proved similar. A good timeline preserves uncertainty and helps reviewers understand which decisions were reasonable at each moment.
Use the timeline to improve the system
After recovery, look for detection gaps, slow decisions, unclear ownership, communication delays, failed automation, and repeated manual work. The purpose is not to grade individuals minute by minute. It is to identify which parts of the operating system made the incident harder to detect, contain, communicate, or resolve.
Key idea
Record what was known at the time, who acted, what changed, and what evidence supports the entry.