🚨 The Cold Postmortem: Why Writing It Too Late Wrecks the Analysis

Overview

A “cold” postmortem is one written so long after the incident that the evidence has degraded before anyone captured it. Human memory of a stressful, fast-moving incident decays within days; log retention windows expire; dashboards roll off their high-resolution data; and the temporary Slack channel gets archived. When the document is finally written three weeks later, the author is reconstructing the incident from fragments and from what people think they remember, which is a very different thing from what happened.

This failure mode is insidious because the resulting document can still look complete. It has a timeline, a root cause, and action items. What it lacks is fidelity: the timestamps are approximate, the causal chain is smoothed over, and the specific evidence that would let you verify the root cause is gone. A postmortem is only as good as the evidence behind it, and the single biggest threat to that evidence is time. The fix is not writing longer documents — it is writing them while the incident is still warm.

Symptoms

Cold postmortems have a recognizable texture once you know what to look for.

• The timeline uses vague times (“around mid-morning,” “later that afternoon”) instead of precise timestamps.
• Key evidence is described as “we believe” or “as I recall” rather than linked to a log line, graph, or message.
• Links to dashboards return “no data for this range” because retention expired.
• The root cause is plausible but unverifiable — nobody can point to the artifact that proves it.
• Responders give conflicting accounts of the same moment and the doc silently picks one.
• The postmortem is dated many days or weeks after the incident’s resolution.
• Action items are generic because the specific failure details needed to scope them are lost.

Common Root Causes

• No SLA for writing the postmortem. If “write it within X business days” is not a policy, it slips behind feature work indefinitely.
• No single owner assigned at incident close. When everyone is responsible, nobody drafts it, and the delay compounds.
• Evidence was never snapshotted during the incident. Logs, graphs, and chat transcripts were left in place to expire rather than exported while fresh.
• Short retention windows. Log and metrics retention (often 7–30 days, sometimes hours at high resolution) quietly deletes the proof before the writer needs it.
• Ephemeral incident channels. The dedicated Slack/Teams channel — the richest timeline source — gets auto-archived or deleted.
• Waiting for a “complete” picture. Teams delay writing until every detail is known, and by the time it is, the easy-to-capture details have rotted.
• Reorg or handoff. The person who ran the incident leaves the team before writing it up, and their firsthand memory leaves with them.

Diagnostic Workflow

Use this to judge whether a postmortem is cold and how much fidelity has already been lost.

1. Check the age gap. Compare the incident resolution date to the postmortem draft date. Beyond roughly 3–5 business days, assume memory decay is material.
2. Audit evidence links. Click through every referenced dashboard and log query. Count how many return “no data” or a truncated range — that fraction is your evidence-loss rate.
3. Scan for hedge language. Flag every “I think,” “around,” “roughly,” and “as I recall.” High density means the timeline is memory-based, not evidence-based.
4. Cross-check accounts. Where two responders describe the same moment, verify the doc reconciled them against a primary source rather than choosing one narrative.
5. Test the root cause for provenance. Ask: what artifact proves this root cause? If the honest answer is “nobody kept it,” the conclusion is a hypothesis wearing a conclusion’s clothes.
6. Check channel and ticket retention. Confirm the incident channel and monitoring data for the incident window still exist; note anything already expired.

Example Root Cause Analysis

A payments API had a two-hour latency spike. The postmortem was written 24 days later, after the quarter-end crunch. The draft’s root cause read: “A downstream provider likely had a slow period; latency recovered on its own.”

Running the diagnostic workflow exposed how cold it was. The high-resolution latency dashboard only retained 14 days at one-minute granularity, so the exact shape of the spike was gone. The incident Slack channel had been auto-archived and purged at 21 days, taking the responders’ real-time notes with it. Two engineers remembered the timeline differently — one recalled a deploy that day, the other did not — and the doc had simply gone with “no deploy.” The “downstream provider” theory rested entirely on one person’s recollection with no supporting log.

The deeper root cause was not the latency at all; it was that the organization had no mechanism to preserve incident evidence. When the team later added a step to snapshot dashboards and export the incident channel at resolution, a similar spike two months on was traced in minutes to a connection-pool exhaustion after a deploy — the exact kind of specific, verifiable cause the cold postmortem could never have reached. The real fix was process: capture evidence while it is warm, and write within days.

Prevention Best Practices

• Set a postmortem SLA. Require a draft within a fixed window (commonly 2–5 business days) of incident resolution, and track it like any other commitment.
• Assign the author at close. Before standing down an incident, name one owner for the postmortem so it never falls into the “everyone/no one” gap.
• Snapshot evidence during the incident. Export or screenshot the key dashboards, save relevant log queries, and pin critical messages before the channel and retention windows expire.
• Preserve the incident channel. Auto-export the dedicated channel transcript to the postmortem doc or ticket at resolution rather than letting it be archived away.
• Extend retention for incident windows. Where possible, tag or copy the metrics and logs covering the incident period so they outlive the default retention.
• Start the doc during the incident. Keep a running timeline in real time; a warm skeleton written live beats a cold reconstruction every time.
• Capture firsthand accounts fast. Do a brief responder debrief within a day, while memory is still detailed, especially before anyone changes teams.

Quick Reference

• Symptom: vague times and “as I recall” → memory-based, not evidence-based.
• Symptom: dashboard links show “no data” → retention expired before capture.
• Symptom: draft dated weeks after resolution → cold postmortem, expect fidelity loss.
• Fix: set and enforce a 2–5 business-day postmortem SLA.
• Fix: assign a single author before standing down the incident.
• Fix: snapshot dashboards, log queries, and the incident channel at resolution.
• Fix: keep a running timeline live during the incident, not from memory afterward.

Conclusion

The quality of a postmortem is bounded by the quality of the evidence behind it, and evidence has a short shelf life. Memory blurs in days, chat channels get archived, and high-resolution telemetry rolls off before you go looking for it. A postmortem written too late can still be well-formatted and confidently worded while resting on almost nothing verifiable — which is arguably worse than an honestly incomplete one, because it launders guesses into conclusions. Keep the record warm: assign an owner immediately, capture the evidence during the incident, and write while the details are still sharp. A rough draft written on day one will always beat a polished reconstruction written on day thirty.