Engineering & IT

Turn an incident timeline into a draft

The boring half of a postmortem written for you, leaving the causes to the humans.

Time
13 minutes
You work in
Documents
Connect first
PagerDuty

Before you start

  • PagerDuty connected
  • A recent incident to write up

Postmortems have a participation problem, not a value problem. Everyone agrees they matter; writing one takes two hours the week after the incident, when the crisis has passed and the work has piled up.

So they are written late, thinly, or not at all.

Split the mechanical half from the thinking half

A postmortem is two documents pretending to be one. The timeline — what happened, when, who did what, what the graphs showed — is transcription. The analysis — why it happened, what we will change — is judgement.

Only the first can be automated, and it is most of the typing.

Draft the timeline from the record

Prompt
Draft the timeline section of a postmortem for this incident.

From the incident record and the channel:
  when it started, and how we know
  when we noticed, and how
  what we did, in order, with times and who
  when it was mitigated and when it was resolved
  customer impact: what was broken, for whom, for how long

Report only what the record shows. Where the record is ambiguous, say so
rather than smoothing it into a clean sequence.

Do not write a cause. Do not write action items. Leave those sections
empty with their headings.

"Do not write a cause" is the instruction that keeps the document honest. A plausible cause written into the draft becomes the cause, because everyone reviewing is busy and it is already on the page. Causation is the one part of a postmortem that has to be argued by the people who were there, and handing them a confident first draft of it quietly removes the argument.

Note the ambiguity rather than resolving it

"Between 14:05 and 14:20 it is unclear whether the restart had taken effect" is a more useful sentence than a tidy timeline that picks one. The gaps in your record are themselves a finding: they are where your observability was thin.

Fill in the thinking half within a week

The draft removes the excuse, not the work. Bring the timeline to the review with the causes and actions blank, and spend the meeting on those.

That is the correct use of the hour, and it is the part nobody was ever reluctant to do.

Feed actions back into the runbooks

Postmortem actions that become tasks get done; ones that stay in the document do not. If the action is "the runbook was wrong", that is an edit somebody owns.

What good looks like

A timeline draft exists within an hour of resolution, and the postmortem meeting is entirely about why rather than about reconstructing what.

The measure is how many postmortems get finished. If drafts are produced and never completed, the blocker was never the typing.