🕰️ Timeline Reconstruction for Postmortems: A Practical Method

The timeline is the spine of a postmortem. Every other section — root cause, impact, action items — rests on it, and if the timeline is wrong or vague, the analysis built on top is worthless. Yet timelines are the part most often reconstructed from memory in a meeting, which is exactly how they go wrong. This guide is a practical method for building a timeline from evidence, quickly and accurately.

Why memory is the enemy

Human memory of a stressful incident is unreliable in specific, predictable ways: people compress time (a twenty-minute diagnosis feels like five), reorder events to fit the story they’ve since constructed, and unconsciously smooth over the confusing parts. Ask three responders when the alert fired and you’ll get three answers, none exact. So the first rule of timeline reconstruction is: build from artifacts, then let people annotate — never the other way around.

The sources, in order of reliability

Gather evidence before you write a word. Ranked from most to least trustworthy:

1. Machine timestamps. Deploy logs, alert firing times, CI/CD records, autoscaler events, config-change audit logs. These are ground truth. Start here.
2. Chat scrollback. The incident channel is a timestamped record of what people knew and when. Invaluable, because it captures the human timeline — when someone first suspected the database, when the theory changed.
3. Graph and dashboard screenshots. Metrics show when things actually degraded and recovered, which often differs from when humans noticed.
4. Ticket and page history. When the page fired, when it was acknowledged, when it escalated.
5. Human memory. Last, and only to fill gaps and add the why behind actions the artifacts can’t explain.

Normalize everything to one timezone — UTC is the safe default — before you merge sources. The most common timeline error is mixing local times and creating phantom gaps or overlaps.

The method, step by step

1. Set the boundaries. Fix a start (first anomaly, even if undetected) and an end (full recovery confirmed). Everything lives between them.

2. Dump raw events into one list. Pull every timestamped event from your sources into a single chronological list. Don’t filter yet — over-collect. It’s easier to trim than to remember later.

3. Mark the five anchor moments. Every incident has these, and they drive your key metrics:

• Started — when impact actually began (often before detection).
• Detected — when a human or alert first knew.
• Acknowledged — when someone owned the response.
• Mitigated — when impact stopped or was contained.
• Resolved — when the system was fully back to normal.

4. Compute the gaps. The interval between started and detected is your detection gap — usually the biggest and most overlooked lever on total incident time. The interval between detected and mitigated is your response time. Naming these two gaps explicitly is half the value of the whole exercise.

5. Trim to meaningful events. Now cut the noise. Keep first symptom, alerts, key diagnostic findings, decisions, actions taken, and recovery. Drop the routine chatter.

6. Annotate with the why. This is where humans come in. Beside key actions, add the reasoning: “Restarted the pod — theory was a memory leak (wrong, but reasonable given the OOM logs).” The annotations turn a log into a learning document.

A timeline format that works

Use a table. It’s scannable and forces you to timestamp everything.

## Timeline (all times UTC, YYYY-MM-DD)

| Time  | Event                                              | Source        |
|-------|----------------------------------------------------|---------------|
| 14:02 | Deploy orders-service v2.3.1 begins                | deploy log    |
| 14:06 | Orders API p99 latency climbs past 3s [STARTED]    | grafana       |
| 14:11 | Automated latency alert fires [DETECTED]           | alertmanager  |
| 14:14 | On-call acknowledges, opens #inc-1042 [ACK]        | pagerduty     |
| 14:19 | First theory: downstream cache — ruled out 14:24   | chat          |
| 14:29 | Slow migration identified holding table lock       | chat + db log |
| 14:33 | Migration killed; latency recovers [MITIGATED]     | grafana       |
| 14:40 | Full recovery confirmed, incident closed [RESOLVED]| chat          |

**Detection gap (started → detected): 5 min**
**Response time (detected → mitigated): 22 min**

The bracketed anchors and the two computed gaps at the bottom are what make this a diagnostic tool rather than a log dump.

Common mistakes

• Reconstructing live in the meeting. Build it beforehand from artifacts; use the meeting to correct and annotate.
• Mixing timezones. Normalize to one zone first, always.
• Recording only what humans did. The machine timeline (when it actually broke vs. when you noticed) is where the detection gap hides.
• No “started” before “detected.” If your timeline begins at the alert, you’ve hidden your biggest finding.
• Dropping the dead ends. The theory that was wrong but reasonable is valuable — it shows where the system misled responders.

Wrapping up

A good timeline is built from machine timestamps and chat scrollback, normalized to one timezone, anchored on the five key moments, and annotated with the reasoning behind each action. Get it right and the detection gap and response time fall out for free — and every downstream section of the postmortem inherits a foundation you can trust. Build it from evidence, not memory, and build it before the meeting.

Related

• Reconstructing an Incident Timeline From Chat Logs With AI
• Running Incident Retrospectives: A Facilitator’s Template
• Incident Metrics That Matter: MTTA, MTTR, MTBF