An incident timeline is not a courtroom transcript. It is a shared map of events that helps a team separate observation from interpretation.
Record facts first
Use a consistent timestamp, a short event, and a source:
09:14 UTC Deploy 4c91 completed in production. [CI]
09:18 UTC Error rate crossed 2%. [metrics]
09:22 UTC Checkout team acknowledged the alert. [incident chat]
09:31 UTC Rollback completed. [deployment log]Avoid phrases like “the database suddenly broke” until the evidence supports that explanation. “Database latency increased” is both more precise and easier to verify.
| Include | Avoid |
|---|---|
| Exact times | Approximate memories |
| Links to evidence | Unverifiable conclusions |
| User impact | Blame |
| Mitigation steps | Private speculation |
End with unknowns
An honest timeline can include questions:
- Why did the canary pass?
- Which alert fired first?
- Did cached responses hide the impact?
Unknowns are not gaps to hide. They are the next investigation.