How to Write a Postmortem Timeline in English

Learn the English phrasing for writing a clear, precise incident timeline in a postmortem, from detection through resolution.

A postmortem timeline is the backbone of the whole document — everything else (root cause, impact, action items) hangs off a clear sequence of what happened and when. A vague or emotionally hedged timeline (“things started going wrong around the afternoon”) undermines trust in the whole postmortem, while a precise one (“at 14:02 UTC, error rates crossed 5%”) lets readers reconstruct exactly what happened without guessing.

Key Vocabulary

Timestamping precisely — anchoring every event in the timeline to a specific, consistent time zone (usually UTC), so readers across regions can follow the sequence without doing mental time zone math. “I timestamped precisely: at 14:02 UTC, the deploy completed; at 14:04 UTC, error rates began climbing.”

Distinguishing detection from occurrence — separating when a problem actually started from when it was noticed, which is often a meaningfully different and important gap to call out. “I distinguished detection from occurrence: the underlying issue started at 14:04 UTC, but our alert didn’t fire until 14:19 UTC, a 15-minute detection gap.”

Describing actions taken, not just events observed — recording what responders actually did at each step, not only what the system was doing, so the response itself can be evaluated afterward. “I described the actions taken: at 14:22 UTC, the on-call engineer rolled back the deploy; at 14:25 UTC, error rates began recovering.”

Marking resolution clearly — stating explicitly when the incident was considered resolved, and by what criteria, rather than letting the timeline trail off ambiguously. “I marked resolution clearly: the incident was declared resolved at 14:40 UTC, once error rates had been below baseline for ten consecutive minutes.”

Common Phrases

  • “At [HH:MM UTC], [specific event, stated factually].”
  • “This was first detected at [time], via [specific alert/report], [X minutes] after the underlying issue began.”
  • “At [time], [responder/team] took [specific action], which resulted in [observed effect].”
  • “The incident was declared resolved at [time], based on [specific criteria].”
  • “Between [time] and [time], [ongoing condition, e.g. error rates remained elevated].”

Example Sentences

A precise, well-structured timeline excerpt: “14:02 UTC — Deploy of v2.14.0 completes. 14:04 UTC — Error rate on the checkout endpoint begins climbing, from a baseline of 0.1% to 8%. 14:19 UTC — PagerDuty alert fires and the on-call engineer acknowledges. 14:22 UTC — On-call engineer identifies the deploy as the likely cause and initiates a rollback. 14:25 UTC — Rollback completes; error rate begins recovering. 14:40 UTC — Error rate has remained below 0.2% for ten minutes; incident declared resolved.”

Calling out a detection gap explicitly: “There was a 15-minute gap between when error rates first began climbing (14:04 UTC) and when our alerting fired (14:19 UTC) — this gap is addressed in the action items below.”

Avoiding vague, unanchored language: Instead of “things got worse in the afternoon,” write: “between 14:04 UTC and 14:19 UTC, error rates rose steadily from 0.1% to a peak of 12%.”

Recording an action that didn’t immediately resolve the issue: “14:10 UTC — First mitigation attempt (restarting the affected service) is applied; error rates do not improve. 14:22 UTC — Root cause is identified as the deploy, and a rollback is initiated instead.”

Professional Tips

  • Anchor every timestamp to a single, consistent time zone (UTC is standard), and state it explicitly at the top of the timeline.
  • Separate occurrence, detection, and resolution as distinct, individually timestamped moments — conflating them hides gaps worth addressing.
  • Write timeline entries as factual, observable events (“error rate reached 8%”) rather than interpretive language (“things got bad”) — save interpretation for the root cause section.
  • Include failed mitigation attempts in the timeline, not just the fix that worked — they’re often relevant to understanding the response and worth learning from.
  • State the specific criteria used to declare resolution, since “it seemed fine” is a much weaker closing statement than “error rate remained below baseline for ten consecutive minutes.”

Practice Exercise

  1. Write three consecutive timestamped timeline entries for a hypothetical incident, using UTC.
  2. Write a sentence explicitly calling out the gap between occurrence and detection.
  3. Rewrite the vague sentence “things got worse around midday” as a precise, timestamped entry.