how to keep an incident timeline automatically
Shows how to keep an incident timeline automatically by logging timestamped events to a file during the incident and pulling in deploy and alert history after. Use to make postmortems write themselves. Does not replace the postmortem analysis itself.
TL;DR
Pipe chat messages, deploy events, and alert notifications into a timestamped timeline file during the incident, so the postmortem writes itself. Manual timelines get reconstructed from memory and miss half the events. Automatic capture is cheap: a bot or a shared file that logs every key event with a UTC timestamp as it happens.
Error / query
how to keep an incident timeline automaticallyEvery postmortem starts with "so what actually happened, in order?" and nobody remembers. You want the timeline to build itself.
Use this skill when
- postmortems stall because nobody can reconstruct the order of events
- you want timeline capture without assigning someone to be the scribe
- timelines keep getting rebuilt from memory and chat scrollback
- youre setting up incident tooling for the first time
Not for this skill when
- you need the postmortem template itself (a different skill)
- you need a vendor timeline product evaluation (a buying question)
- the incident is over and you just need to write up what you remember
Steps
1. Create the timeline file the moment the incident starts
One file, UTC timestamps, created at declaration time. Everything after gets appended.
echo "# Incident timeline - started $(date -u +%Y-%m-%dT%H:%M:%SZ)" > ./incident-timeline.md
echo "" >> ./incident-timeline.md
cat ./incident-timeline.mdExpected: a timestamped timeline file exists. From here on, every key event is one appended line.
2. Log key events as they happen with a one-liner
Detection, escalation, mitigation attempts, all-clear. One line each, timestamped, with a category tag.
echo "- $(date -u +%H:%M:%S) [detection] error rate alert fired for payments-api" >> ./incident-timeline.md
echo "- $(date -u +%H:%M:%S) [declared] SEV1 declared, [name] is incident commander" >> ./incident-timeline.md
tail -5 ./incident-timeline.mdExpected: each event is one line with a UTC timestamp and a category tag. Anyone reading it later can reconstruct the incident.
3. Pull alert and deploy history into the timeline after
After the incident, append the objective record: deploys and alert firings around the window. This fills the gaps humans missed.
git log --since="2 hours ago" --oneline >> ./incident-timeline.md
echo "--- deploy history appended ---"
tail -20 ./incident-timeline.mdExpected: the timeline now includes deploys alongside the manual entries. Gaps and correlations become visible at a glance.
Variant phrasings
automatic incident timeline tool
Same fix: the file-plus-one-liner method above is the simplest automatic timeline. Graduate to a chat bot that logs channel messages when the volume justifies it.
how to document an incident as it happens
Same fix: steps 1 and 2 are the documentation. One file, timestamped lines, no prose required during the fire.
incident log template
Same fix: the category tags ([detection], [declared], [mitigation], [resolved]) are the template. Consistent tags make the timeline greppable later.
Why it happens
Humans are bad at remembering times under stress, and chat scrollback is a terrible timeline: jokes, side threads, and duplicate reports bury the signal. A dedicated timeline with one line per event survives the chaos because appending one line is cheap enough to do mid-incident.
Edge cases and pitfalls
- Chat history gets deleted or is unexportable: the timeline file is the durable record, so keep it in the repo, not just in chat.
- Multiple channels in play: designate one as the timeline source at declaration time, or the timeline splits.
- Sensitive data lands in the log: scrub customer data before the timeline leaves the incident channel.
- Timezone confusion in a global team: always UTC in the timeline, no exceptions.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_LEHRrW6W7hnjOKo61MgGYg
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.