🚨 Postmortem Anti-Pattern: Incomplete and Inaccurate Incident Timelines

Overview

The timeline is the spine of a postmortem. Every conclusion about what caused an incident, how long detection took, and whether the response was effective rests on an accurate sequence of when things actually happened. An incomplete or inaccurate timeline — one with unexplained gaps, timestamps reconstructed from memory, mixed time zones, or no authoritative source — does not merely weaken the analysis; it corrupts it. If the timeline says detection took two minutes when it really took twenty, every downstream metric and every action item aimed at “response was fine” is built on a false foundation.

This anti-pattern is insidious because a bad timeline still looks like a timeline. It has rows, it has timestamps, it reads convincingly. But the errors hide in what is absent and what is guessed: the fifteen-minute window nobody can account for, the “~2:30pm (approx)” that was really 2:52, the alert time pulled from a chat message rather than the monitoring system. Because everyone downstream trusts the timeline, its errors propagate silently into the root cause, the metrics, and the lessons. Getting the timeline right — sourced, complete, and in one time zone — is the least glamorous and most load-bearing work in the whole postmortem.

Symptoms

• Unexplained gaps — long stretches between rows with no entry, where the story simply skips ahead.
• Hedged timestamps — ”~”, “approx,” “around,” “sometime after” — signalling memory, not measurement.
• Mixed or unstated time zones — some rows in UTC, some in local, some ambiguous, making ordering unreliable.
• No source column — entries with no indication of where the timestamp came from (log, alert, chat, memory).
• Detection time that doesn’t match monitoring — the timeline’s “alert fired” differs from what the alerting system actually recorded.
• Rows added from memory days later — reconstructed after the fact with false precision.
• Contradictions between the timeline and the logs that nobody reconciled before publishing.
• A suspiciously flattering sequence — detection and response look fast because the slow parts fell into the gaps.

Common Root Causes

• No real-time incident log. Nobody captured timestamps as events happened, so the timeline is reconstructed entirely from memory afterward.
• Multiple clocks, no reconciliation. Logs in UTC, chat in local time, someone’s laptop skewed — and no one normalized them to a single reference.
• Memory presented as measurement. People genuinely misremember timing under stress, and “I think it was about 2:30” gets written down as fact.
• No designated scribe. During the incident everyone is fighting the fire and no one owns recording the sequence, so the record has holes.
• Source systems not consulted. The author writes from recollection and Slack scrollback instead of pulling authoritative timestamps from logs, alerts, and deploy records.
• Gaps treated as unimportant. A window where “nothing happened” is left blank, when in fact that window is often where detection or escalation silently stalled.
• Publishing pressure. The timeline is finished quickly to ship the doc, before anyone reconciles it against the source-of-truth systems.

Diagnostic Workflow

Treat the timeline as evidence that must be sourced, not a story that can be told. Every row needs a provenance: where did this timestamp come from, and is that source authoritative?

Source-of-truth ranking for a timestamp (prefer higher):
  1. Monitoring/alerting system record (fired-at, resolved-at)
  2. Structured logs / traces with server timestamps
  3. Deploy & CI/CD system events
  4. Ticketing / incident tool audit trail
  5. Chat message timestamps (ordering only — humans lag events)
  6. Human memory  <- lowest; flag every row that rests on this

Then run a completeness and consistency pass over the assembled timeline:

Timeline audit checklist:
  [ ] Every row has a SOURCE noted (system + which record)
  [ ] All timestamps in ONE time zone (UTC recommended), stated once
  [ ] No unexplained gap > a few minutes during the active incident
  [ ] Detection time matches the ALERTING SYSTEM, not a chat message
  [ ] Any "~" / "approx" is either sourced precisely or labeled ESTIMATE
  [ ] Timeline order does not contradict the logs
  [ ] Key milestones present: onset, first signal, alert, ack,
      escalation, mitigation start, recovery, all-clear

For every remaining gap, ask specifically: what was happening in this window, and why is there no record? Gaps are not empty — they are usually where detection lagged, an alert failed to route, or an escalation stalled. The missing minutes are frequently the most diagnostic minutes in the whole incident.

Example Root Cause Analysis

Incident: An API degraded, causing elevated latency for customers; the postmortem needs to assess whether detection and response were adequate.

Inaccurate-timeline draft:

2:30pm  API started having problems
2:35pm  On-call noticed and started investigating
2:45pm  Fixed it, recovered

What’s wrong with it:

1. All timestamps are round and hedged — “2:30,” “2:35,” “2:45” are memory, not measurement; the five-minute regularity is a tell.
2. No source column — none of these came from a system of record; they came from recollection after the fact.
3. A hidden gap — “on-call noticed at 2:35” quietly skips how detection happened and how long the alert actually took.
4. Detection looks great by accident — a 5-minute detect and 15-minute total, both of which the source data contradicts.

What the source-of-truth systems actually showed:

• Alerting system: latency alert fired at 2:38pm UTC, but routed to a deprecated channel; on-call was paged at 2:51pm after a manual escalation.
• Logs: latency began climbing at 2:26pm UTC, twelve minutes before the alert.
• Deploy system: a config change shipped at 2:24pm UTC, immediately preceding onset.
• Incident tool: mitigation (config rollback) started 3:02pm, recovery confirmed 3:09pm UTC.

Corrected, sourced timeline:

02:24 UTC  config change deployed            [deploy system]
02:26 UTC  latency begins climbing           [service logs]
02:38 UTC  latency alert fires               [alerting system]
02:38-02:51 alert routed to dead channel;
           no human ack                      [alert audit trail — GAP explained]
02:51 UTC  on-call paged via manual escalation [incident tool]
02:53 UTC  on-call acks, begins investigating [incident tool]
03:02 UTC  config rollback started           [incident tool]
03:09 UTC  recovery confirmed                [alerting system]

What the accurate timeline reveals that the guessed one hid: true customer impact was ~43 minutes, not 15. Detection-to-page took 13 minutes because the alert routed to a dead channel — a finding completely invisible in the original. The action items change entirely: fix alert routing and add ack-timeout escalation, rather than the original’s implicit “response was fine.”

Prevention Best Practices

• Keep a real-time incident log. Assign a scribe at declaration whose only job is timestamping events as they happen, so the timeline is captured, not reconstructed.
• Source every row. Require a provenance note on each entry — which system and which record the timestamp came from — and rank memory lowest.
• Normalize to one time zone. Standardize on UTC (or one stated zone) across logs, chat, and the doc, and reconcile clock skew before publishing.
• Pull from systems of record. Build the timeline from alerting, logs, deploy, and incident-tool audit trails first; use chat and memory only to fill narrative color, never core timing.
• Interrogate every gap. Treat any unexplained window as a finding to investigate, not a blank to skip — the missing minutes are usually where detection or escalation stalled.
• Label estimates as estimates. If a timestamp genuinely can’t be sourced, mark it ESTIMATE explicitly so no one treats a guess as a measurement.
• Reconcile before publishing. Cross-check the timeline against the logs one final time; a timeline that contradicts the source data must be fixed, not shipped.

Quick Reference

# Timeline gaps = missing/guessed/unsourced timestamps that corrupt the analysis.

Source-of-truth ranking (prefer higher):
  alerting system > structured logs > deploy events > incident-tool audit
  > chat (ordering only) > human memory (flag it)

Audit before publish:
  [ ] every row SOURCED (system + record)
  [ ] ONE time zone, stated (UTC)
  [ ] no unexplained gap during active incident
  [ ] detection time == alerting system, not chat
  [ ] "~"/"approx" sourced precisely or labeled ESTIMATE
  [ ] order does not contradict the logs
  [ ] milestones present: onset, alert, ack, escalate, mitigate, recover

Every gap is a finding:
  ask "what happened here and why is there no record?"
  -> usually where detection/escalation silently stalled

Conclusion

An incident timeline is not a narrative you tell from memory; it is evidence you assemble from systems of record, and its accuracy sets a ceiling on the accuracy of everything built on top of it. A timeline riddled with gaps, guessed timestamps, and mixed clocks will produce a postmortem that is confidently, invisibly wrong — flattering detection numbers, hidden escalation failures, and action items aimed at problems you never actually had. The discipline is unglamorous but decisive: capture events in real time with a scribe, source every row to an authoritative system, normalize to a single time zone, and treat every gap as a question rather than a blank. Get the spine right and the rest of the postmortem can stand on it; get it wrong and no amount of downstream analysis can recover, because you are reasoning carefully about events that never happened the way the timeline claims.