Consider a fictional postmortem titled “INC-2024-017: API latency degradation.” Six months later, a new teammate searching the incident index might still be unable to tell from that title what failed or which fix mattered. This worked example shows how a timeline, causal explanation, and precise title can make an incident record useful to someone who was not in the room. The team, outage, documents, times, and metrics below are invented to demonstrate the method; they are not Gray Haven Lab’s observed history.

A fictional incident to work through

Imagine a four-person team running a PostgreSQL primary with a streaming replica. In this invented scenario, a Tuesday 14:10 UTC page reports elevated 5xx rates on a checkout API; service returns to baseline around 14:50. The times and impact are illustrative, not measurements from a real outage. They give the postmortem exercise a concrete sequence to test.

Suppose the exercise provides chat messages, application logs, a dashboard capture, and an alarm history. The task is to determine what each artifact can establish, where the first draft overstates a conclusion, and what a later reader would need to verify it.

Chronology is not a narrative

A first draft can become a flat timeline: timestamp, event, timestamp, event. It may record the sequence without explaining which events changed the outcome. Accuracy matters, but a useful postmortem also identifies the failure mechanism and the evidence for it.

A timeline entry such as “14:12 — on-call acknowledged page” records an event. A stronger entry would say “14:12 — page acknowledged; responders checked the load balancer first because the alert did not name the checkout API”, if the chat and logs support that account. The second version tells a future reader why those minutes mattered. The writing analogy is a way to test the explanation, not evidence that the incident occurred.

For this fictional case, organize the evidence into three questions rather than forcing every timestamp into an act structure:

• Before the alert. What was normal, and which condition made the failure possible? The invented records show a connection pool approaching its limit before a deployment increased query traffic. A real postmortem would need metrics to establish the timing.
• The turning point. In the worked example, pool exhaustion queues health checks, targets are marked unhealthy, and traffic shifts to fewer app nodes before the page fires. The alert is an observation of the failure, not necessarily its first cause.
• Resolution and follow-up. Record the action taken, the measurements that showed recovery, and the permanent change proposed. Do not treat “error rate returned to baseline” as a substitute for evidence that the cause is understood.

This analysis takes more time than pasting a timeline. Spend that time where the incident reveals a new failure mode or meaningful customer impact. For a repeat of a known issue, a shorter record may be enough if it still links the evidence, decision, and follow-up.

Reconstructing the timeline from Slack, not memory

People in the same incident can remember its order differently. Reconstruct the sequence from available artifacts and record their limits:

1. Preserve the incident channel within the organization’s retention rules. Keep message timestamps and relevant context, subject to access and privacy controls. Chat is one clock, not the only authoritative record.
2. Compare chat with application logs and metrics. Chat shows what responders believed; logs and metrics show what systems recorded. Neither is infallible. In this fictional checkout case, the chat focuses on a recent deploy while the sample metrics place pool saturation earlier. A real report would show the timestamps and queries behind that conclusion.
3. Mark belief changes explicitly. Annotate each working hypothesis and the evidence that supported or challenged it. For example: “14:19 — hypothesis: bad deploy; counterevidence: pool metric already saturated at 13:58.” In a real report, attach the underlying metric and note its clock source.
4. Separate the incident timeline from the communication timeline. Record when status updates went out, what they said, and which observations supported them. Parallel columns make any gap visible without inventing motives.

One caution: a postmortem can inherit the tone of a hurried chat. Keep supported claims about systems; remove speculation about people. “The dashboard was green, so responders initially checked another service” can be a finding if the artifacts show it. “Dana was slow” is a judgment that does not identify a mechanism.

Naming the failure mode like a chapter, not a ticket

Here’s where the craft matters most. Compare two titles for the same incident:

• “INC-2024-017: API latency degradation”
• “The Green Dashboard That Hid a Saturated Connection Pool for Two Weeks”

The first is a filing label. The second is a compressed argument: it names the misleading signal (the dashboard), the real failure (pool saturation), and the duration of the hidden condition (two weeks). Someone scanning the postmortem index six months later can tell from the second title that this is the document to read before they trust their own replica dashboards. The first title tells them nothing except that an incident existed.

A useful title rule is to name the failure mode, mechanism, and, when supported, the surprise. “Replica promoted but lost the last 40 seconds of writes” and “Health check passed while the pool behind it was exhausted” are hypothetical examples of that form. “Database issues on Tuesday” is too vague to guide a later search.

Incident titles can benefit from the same revision question as any short title: what central tension should a reader understand before opening the document? Draft a few options from the verified failure mechanism, then test whether each one names a cause instead of a symptom.

Before publishing a real postmortem, ask someone who was not on the incident whether the title alone indicates the category of failure and the first system they would check. If it does not, revise the title after the timeline and root-cause evidence agree. The title helps readers locate the report; its precision should come from the investigation.

What the worked example suggests changing

The fictional record suggests three revisions. First, write the title after reconstructing the timeline, so the first hypothesis does not become the headline. Second, include enough pre-alert metrics to show whether an enabling condition existed before the page fired. Third, keep the narrative concise: split independent failure modes into separate findings instead of letting an elaborate story hide the evidence.

A postmortem serves someone who was not present: a new hire, a future responder, or an engineer deciding whether to repeat an architectural choice. Chronology is necessary but not sufficient. A clear causal account, linked to artifacts and titled for the verified failure mode, gives that reader a way to test the lesson.