| name | incident-postmortem |
| description | Create an evidence-backed, blameless postmortem after a production incident has stabilized. Use for material outages, degradation, data loss, emergency rollback, manual intervention, or monitoring failure. Do not use during active response or for routine failed deployments; do not operate production unless separately authorized. |
Incident Postmortem
Turn incident evidence into shared understanding and corrective actions that reduce recurrence, detection time, and recovery time.
Read references/evidence.md when reconstructing causes or defining corrective actions. If delegation is explicitly authorized, apply delegate-work to gather independent evidence lanes such as telemetry, deployment history, or response timeline; keep impact, causal synthesis, and the final narrative under one owner.
Confirm the boundary
- Verify that the incident is stabilized before conducting the full review.
- During an active incident, preserve timestamps, commands, alerts, graphs, deployments, logs, and decisions without distracting responders.
- Do not operate production, contact people, publish the postmortem, or create tracker items without explicit authorization.
- Protect secrets, personal data, customer data, and privileged operational details.
Establish the evidence
- Use a single declared timezone and precise timestamps.
- Gather monitoring data, logs, traces, deploy and configuration history, tickets, communication records, and relevant code changes.
- Separate observed facts, credible inferences, and unknowns.
- Quantify impact only from defensible evidence: affected users or requests, duration, data integrity, regions, products, and business consequences.
- If the technical cause remains uncertain, route the unresolved investigation to
diagnosing-bugs.
Reconstruct the timeline
- Cover the first known contributing condition, trigger, detection, escalation, diagnosis, mitigation, recovery, and confirmation.
