An incident timeline built from a written report is a list of events in the order they happened, each tied to the day or time the text gives for it. The reading order of the document is not that order. Reports are written backwards from the symptom, emails arrive in the order people replied, and half the dates are phrases such as "two days later" that mean nothing without the day they count from. Getting the list right is a matter of a few rules: give relative dates an anchor, keep a date only as precise as the text made it, separate when something happened from when someone wrote about it, keep the words that date each event, and sort by date, never by mention. This guide takes each in turn, then shows a check that can fail.

Why the timeline is the core of the record

Both major public guides on incident review put the timeline first. Google's SRE book describes a postmortem as the written account of what happened, how bad it was, what stopped it, why it happened and what will change (Google SRE book), and its example postmortem has a dedicated Timeline section, opening with a date line and entries that each start with a clock time (Google SRE book, example). PagerDuty's process page tells the team to focus on the timeline to begin with, to include changes in status and impact along with key responder actions, and to back every item with a metric or an outside page that holds the data (PagerDuty).

The last point is the one that matters for automatic extraction. An entry without evidence is a claim. For a program that reads a report and lists its events, the evidence is the sentence the event came from, so the useful output is the event, its date as the text wrote it, the normalised date, and the exact quote.

Rule one: a relative date needs an anchor

"Three days after the outage began, the team rolled back the release." That is a fact only when you know the day it counts from. If the previous sentence gives a full date, the arithmetic is simple, using a calendar that respects short months and leap years: two days after the last day of February lands on a different date in a leap year than in other years. If the sentence opens the text, or the earlier event has only a month, there is no date to compute, and the honest result is an undated event that stays where the story put it.

The tempting error, close to the habit of auditing what an agent says against its log, is to count from the wrong place: from the date of the report, from today, or from a date that "probably" is meant. Each produces a clean-looking calendar day that the text never stated. An undated event on the list beats a dated one with a wrong day, since a wrong day gets believed.

Rule two: a date is as precise as the text, and no more

"In March 2022" is a month. A tidy normaliser turns it into the first of March, and and now the list claims a specific day that the source never gave. The W3C profile of ISO 8601 allows reduced precision by design: a year alone, a year and month such as 1997-07, or a complete date such as 1997-07-16 (W3C date and time formats). Write each date at the precision the source has.

Two related traps:

  • No year. A date such as "5 May" carries none. Borrowing one from a neighbouring date, or from the current year, invents it. Leave the normalised form empty and keep the written words.
  • Numeric dates. The string 03/04/2026 may mean the third of April or the fourth of March. Neither the language of the document nor the writer's country settles it. If a number above twelve sits in either the day position or the month position, it settles itself; otherwise the writer's convention has to come from the text or from whoever asked.

The ISO form also helps the next step. When dates are written year first, then month, then day, sorting the strings alphabetically gives chronological order, as the Wikipedia article on the standard notes (ISO 8601), with exceptions for negative years and for time offsets. That is a reason to store normalised dates in this form, and a reason to treat the offset case separately.

Rule three: when it happened is not when it was reported

Incident writing mixes two clocks. A message sent on Monday may describe a failure from the previous Friday, and a report published in June may discuss a flood from March. Grammar tells you which date belongs to which event. Take "a summary of the outage in March 2025 was sent in June 2026": March 2025 belongs to the outage; the later month belongs to the sending. Hanging both dates on the main verb puts the outage in the wrong year.

Time zones belong here too. The SRE example states in its date line that all times are UTC (Google SRE book, example), one declaration that makes every entry beneath it comparable. The PagerDuty page, in the version read for this guide, gives no time-zone rule, so each team has to choose one. The W3C profile offers two ways to express the choice: the letter Z for UTC, or an explicit offset such as +hh:mm or -hh:mm (W3C date and time formats). When a source text mixes local times from two places without saying so, converting them is a guess; list them as written and flag the problem.

Rule four: keep the phrase that dates the event

When a date is turned into a clean value, the original words should survive next to it. "Early the next morning" and "2026-03-05" are not the same statement: the first can be re-read if the anchor turns out to be wrong, the second cannot. Keeping the exact quote also gives a reviewer a way to verify the entry with a search, which is the PagerDuty requirement of pointing every entry at its evidence in a form a machine can check.

Rule five: do not order by mention

A report that opens with "the site was down on 17 June" and then explains "a certificate had expired on 14 June" lists the cause second. A thread that begins with the apology and ends with the first alert has its events in reverse. Sort by date. Events with equal dates stay in reading order, and undated events go to their own list, again in reading order, rather than being slotted in by guesswork. A sentence like "after that" or "then" fixes a sequence inside the story, not a calendar position, and the list should say no more than that.

A check that can fail

Test the rules on a text where one event has a relative date that must resolve to a specific day, and where the wrong answers are all plausible.

  1. Write a short report with three facts: "The alert fired on 28 February 2028." "Two days later the vendor shipped a fix." "The postmortem was written in April." The last one names no year.
  2. Run it through your extraction. The correct result puts the alert on 2028-02-28 and the vendor fix on 2028-03-01. The postmortem says only "April" with no year, so the year must not be borrowed from the alert, and its normalised date stays empty.
  3. Check that the fix resolved to the first of March. A tool that ignores leap years gives the second. A tool that counts from the report date gives something else entirely.
  4. Now sabotage the input: strip the first sentence and rerun. The vendor fix must now be undated, since that phrase has lost its anchor. If the tool still produces a day, it is guessing, and the pass in step three was luck.

A green result on the intact text proves little by itself. The pass means something because the broken version goes red.

When this does not apply

Only dates inside one pasted text are in scope here. It does not cover reconciling two systems' logs, converting between time zones, or reading timestamps from monitoring data, where the clock source matters more than the wording. It is also about extraction, not about the quality of the postmortem: whether a root cause is deep enough, or the review is blameless, is a separate subject in the cited books. The rules come from the cited documentation and from common patterns in written reports; the leap-year example is arithmetic, not a measurement, and no experiment backs the claim that a particular tool fails in a particular way. Where the PagerDuty page and the SRE book differ, for instance on time zones, this guide describes what each page said when it was read, and either may change.

One tool for the extraction step

For the step where a pasted report becomes a list of events, our timeline-from-text skill turns a pasted report into a sorted list: every dated event carries the wording from the source, a normalised date, a brief description and the sentence it came from. A phrase like "two days later" becomes a day only if the report names the starting day; month-only and year-only dates stay that coarse; a missing year or an ambiguous numeric date stays unresolved; and events without a usable date go into a separate list that follows reading order.

Read this post as Markdown: /blog/timeline-from-incident-report.md · Atom feed.