## 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

```text
how to keep an incident timeline automatically
```

Every 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.

```bash
echo "# Incident timeline - started $(date -u +%Y-%m-%dT%H:%M:%SZ)" > ./incident-timeline.md
echo "" >> ./incident-timeline.md
cat ./incident-timeline.md
```

Expected: 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.

```bash
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.md
```

Expected: 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.

```bash
git log --since="2 hours ago" --oneline >> ./incident-timeline.md
echo "--- deploy history appended ---"
tail -20 ./incident-timeline.md
```

Expected: 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