Every entry in a security incident timeline should carry a UTC timestamp, what happened, who or what did it, and a link to the evidence behind it, such as a log query, graph or ticket. Mark whether the entry is a fact or an inference. A timeline without evidence is a story.
Why the timeline comes first
PagerDuty's postmortem guidance says the timeline should be the main focus when you start the document. It should include important changes in status or impact and the key actions responders took. For each item, it asks the owner to identify a metric or third-party page where the data came from, such as a graph or a search. It also asks for the commands or queries used to look up data to be posted in the page, so others can see how the data was gathered.
That one habit makes a document checkable, and checkable documents survive the questions that come later from legal, auditors and customers.
A format that works
| Field | Example | Why |
|---|---|---|
| Time (UTC) | 14:32 | Avoids time zone confusion |
| Event | Credential revoked | Plain words |
| Actor | On-call engineer | A role or system, not a name where possible |
| Evidence | Link to log query | Lets a reader verify |
| Type | Fact or inference | Stops guesses hardening into history |
| Note | Detected by a customer report | Captures detection source |
Use one time zone for the whole document. Our guide on UTC and clock sync for incident timelines explains why and how to deal with clock drift.
What to include
- First signal. The earliest evidence of the problem, even if nobody saw it then.
- Detection. When and how you noticed. Atlassian's template asks how time to detection could be improved, even as a thought exercise about halving it.
- Declaration. When it became an incident, and its severity.
- Decisions. Why you chose a path, including the options you rejected.
- Mitigation steps. What you changed and when.
- Recovery and verification. How you knew it was over. See verify recovery before you declare the incident over.
What to leave out
- Speculation about motive or attribution. Our post on not speculating in public explains the risk.
- Personal judgments. Google's Workbook says a postmortem is a factual artifact free from subjective language, and shows examples of animated phrasing to avoid.
- Customer or personal data. Google notes its internal postmortems never contain information that identifies an end user. Apply the same rule.
Steps to build it
- Export the incident channel with timestamps converted to UTC.
- Pull the first alert, the first human message and the last mitigation action.
- Add entries from logs, tickets and deploy history.
- Attach the evidence link to each row.
- Ask a responder who was not the scribe to check it.
- Mark gaps openly, such as "no logs retained for this period".
How Safeguard fits
For supply chain incidents, a timeline often hinges on when a component entered your builds. Safeguard's SBOM and dependency scanning helps answer that, and you can try a free scan at https://gold.safeguard.sh/scan.
Quick check
Should names go in the timeline?
Prefer roles. Names are fine for credits in the document header, but the timeline should read as events, not people.
What if the evidence has expired?
Say so in the entry and mark it as an inference. It also becomes an action: extend retention for that log source.
Sources
- PagerDuty incident response documentation, postmortem process
- Atlassian incident management handbook, postmortems
- Google Site Reliability Workbook, Postmortem Culture
- Google SRE book, Postmortem Culture
Last reviewed: 19 October 2026.
