A postmortem should leave a fact record

Mon, 24 Aug 2026 00:00:00 +0000

A postmortem earns trust when its claims can be re-checked. That means every phase names the command that produced the fact, not a paraphrase of what someone remembers. The four phases below keep a write-up reviewable at any later time.

Detect: the symptom, with evidence

Start with the smallest verifiable symptom and the command that showed it. A capture is better than a prose description:

$ check-http-headers.sh https://www.xbcatm.com/
HTTP/2 200
content-security-policy: ... script-src 'none' ...
last-modified: Mon, 24 Aug 2026 11:20:54 GMT

If the symptom is that a header changed, the output showing the previous policy and the new one belongs side by side. If it is a failure, include the exit status and the error line.

Scope: how wide, and how you know

State the blast radius with evidence, not adjectives. Fix the boundary you can inspect:

Which hosts or paths reply with the same symptom? One check-http-headers.sh per candidate host answers this.
Does the cache differ from origin? Compare Vary and validators.
Which rollback window applies? Use the TTL that was in force before the change.

Fix: the change and its intended effect

Write the corrective action so it can be replayed. Prefer the smallest change that restores the contract, and name what the post-fix run should show:

# new policy line expected in the response:
script-src 'none'

Verify: the post-incident run

Repeat the detection command after the change and show that the observed output now matches the intended contract. A postmortem without this final section is a story; with it, it is a record that approves its own future re-check.

Sources