Post-mortem template exists
Why it matters
Without a post-mortem template, email incidents end when sends resume — the root cause, contributing factors, and action items are never formally captured. The same misconfiguration repeats. NIST SP 800-53 IR-5 (Incident Monitoring) and ISO 25010 reliability.recoverability both require that incidents are tracked and that learnings feed back into system improvements. A template is not bureaucracy — it is the mechanism that converts a painful incident into a concrete backlog item that prevents recurrence.
Severity rationale
Low because missing post-mortems cause recurring incidents rather than immediate failures — the impact accumulates over months as the same root causes repeat without structural fixes.
Remediation
Create docs/templates/post-mortem.md with at least five sections:
# Incident Post-Mortem
**Date:** YYYY-MM-DD
**Severity:** P1 / P2 / P3
**Duration:** HH:MM (detection to resolution)
**Affected:** [N emails affected] [N contacts impacted]
## Timeline
- HH:MM — [event]
## Root Cause
[One paragraph]
## Contributing Factors
- [Factor]
## What Worked
- [Item]
## What Didn't Work
- [Item]
## Action Items
| Action | Owner | Due |
|--------|-------|-----|
| | | |
Reference this template from the deliverability incident runbook (docs/runbooks/deliverability-incident.md) so it is findable after every incident. A template with fewer than 5 sections does not satisfy this check.
Detection
-
ID:
post-mortem-template -
Severity:
low -
What to look for: Look for a post-mortem or incident retrospective template in the repository — a markdown file, Notion template link in the README, or documentation structure that guides post-incident analysis. A good template covers: incident timeline, root cause, impact (emails affected, contacts impacted), contributing factors, what worked, what didn't, and action items with owners and due dates.
-
Pass criteria: A post-mortem template exists with at least 5 sections (timeline, root cause, contributing factors, what worked/didn't, action items) and is referenced from the incident response runbook or engineering documentation. Enumerate the sections present in the template.
-
Fail criteria: No post-mortem template exists. Incidents pass without structured retrospective. Or the template has fewer than 5 sections.
-
Skip (N/A) when: The project is a personal side project with a single operator who maintains informal notes — confirmed by a solo contributor history.
-
Detail on fail:
"No post-mortem template found — email incidents are not followed up with structured retrospectives"or"Runbook mentions 'do a post-mortem' but no template or guidance exists" -
Remediation: Create
docs/templates/post-mortem.md:# Incident Post-Mortem **Date:** YYYY-MM-DD **Severity:** P1 / P2 / P3 **Duration:** HH:MM (detection to resolution) **Affected:** [N emails affected] [N contacts impacted] ## Timeline - HH:MM — [event] ## Root Cause [One paragraph] ## Contributing Factors - [Factor] ## What Worked - [Item] ## What Didn't Work - [Item] ## Action Items | Action | Owner | Due | |--------|-------|-----| | | | |
External references
- iso-25010:2011 · reliability.recoverability — Reliability / Recoverability — post-mortem template drives continuous improvement after email incidents
- nist:rev5 · IR-5 — NIST 800-53 IR-5: Incident Monitoring and Reporting
Taxons
History
- 2026-04-18·v1.0.0·Initial import from operational-resilience-email·automated