A postmortem earns trust when its claims can be re-checked. Record each observation’s source, collection time and timezone, command or query, and exit status where relevant. Logs, metrics, and clearly attributed human observations also count; distinguish confirmed facts from hypotheses and preserve redacted evidence rather than secrets. 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. Save the actual capture. The following is an illustrative excerpt, not evidence of a fresh probe:
$ 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. Define the boundary you can inspect:
- Which hosts and paths show the symptom? Record each probed URL and observation time; one successful request cannot establish the state of every edge or visitor.
- Does the cache differ from origin? Compare actual responses, cache metadata, and validators from both paths using the same request headers.
Varydescribes selection inputs, not proof that the response came from cache. - What delays recovery? For a DNS change, record the old TTL and resolver observations. For HTTP caches, record freshness and revalidation policy separately; a DNS TTL is not a universal rollback deadline.
Fix: the change and its intended effect
Record the actual configuration diff and deployment reference so the corrective action can be understood and, where safe, replayed. This header fragment is an expected observation, not a shell command or a complete policy. Prefer the smallest change that restores the contract, and name what the post-fix run should show:
Content-Security-Policy: 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.
Close the record with contributing causes, what remains uncertain, and preventive actions with an owner, due date, and acceptance check. A successful probe confirms that sampled path at that time; it does not establish the cause or prevent recurrence by itself.
Sources
- RFC 9110 — HTTP Semantics, response metadata and conditional requests, checked 2026-07-07.
- artifact HTTP header check, read-only inspection used throughout this record.
- Google SRE: Postmortem Culture, impact, contributing causes, evidence review, and preventive actions, checked 2026-10-15.
- RFC 9111 — HTTP Caching, cache selection and freshness are distinct from DNS cache lifetimes, checked 2026-10-15.