postmortemlisted

# Postmortem Turn a resolved (or mitigated) production incident into a postmortem that reads well for a human and stays parseable by tooling: a numbered spine for the narrative, and a small machine-readable header for anything that scans the file. A postmortem here is a single-author evidence document, not meeting minutes: it is written by whoever ran the investigation, from real telemetry, immediately after mitigation. ## When to write one - Any material production incident (user-visible outage or degradation). - Near-misses and novel failure modes — cheap to write now, expensive to rediscover later. - Investigations that conclude "not actually an incident" — record the evidence so the same alarm doesn't trigger the same investigation twice (use the Investigation variant). Write **immediately** after mitigation. Telemetry retention windows expire (Performance Insights, CloudWatch detailed metrics, APM traces), and timeline precision degrades within days. A postmortem written a week later is reconstructed from memory; one written the same day is transcribed from dashboards. ## File contract — the surfaces a machine can read Postmortems are worth more as a corpus than one at a time, so keep a few surfaces stable and predictable: a severity a reader can filter on and an identity that does not drift. If your project runs tooling that scans postmortems, it will almost certainly key on exactly these two. Nothing below requires such tooling — it is just what makes the set q