engineering-incident-postmortemlisted

# Incident post-mortem ## Purpose Post-mortems fail in three predictable ways: they stop at the trigger ("a bad deploy went out") and call it a cause, they blame a person instead of the conditions that made the error easy, and they end in actions nobody owns. This skill fixes the timeline to evidence, forces the cause analysis past the first plausible answer, and refuses to close on an action without an owner and a date. ## Prerequisites - **Inputs:** the incident record (ID, severity, declared and resolved times); the alert or report that started detection; deploy/change log for the affected services covering the 48h before impact; chat transcript or timeline of responder actions; the customer-visible impact (what broke, for whom, for how long, measured — not estimated). - **Access:** monitoring/dashboards for the impact window, change management records, ticket system to file actions. If the impact window or the change log is missing, say so and stop. A post-mortem built on recollection produces a plausible story and the wrong actions. ## Procedure 1. **Fix the timeline before writing any narrative.** Build a table of timestamped events with a source for each. Every row is one of: a change, a signal, a human action, or a state transition. If a row has no source, mark it `[unverified]` — never silently promote recollection to fact. | Time (UTC) | Event | Type | Source | | --- | --- | --- | --- | | 09:14 | Config change deployed to payments