incident-postmortem

name	incident-postmortem
description	Use after an incident is resolved — drafts a blameless postmortem from timeline notes, alerts, and chat threads.
version	0.1.0
status	experimental
risk	low
tags	["ops","writes-files"]

Incident Postmortem

When to use

• After an incident with customer impact
• After a near-miss worth documenting
• For drills / GameDay exercises

When NOT to use

• Live incidents (use incident-runbook instead)
• Pure private learnings (use a personal log)

Inputs

Name	Type	Required	Notes
timeline	text or paths	yes	Source notes, alert links, chat extracts
severity	S0–S3	yes	Severity at peak
incident_id	string	yes	e.g. INC-2026-04-12-001

Outputs

postmortem.md with: Summary, Impact, Timeline, Direct cause, Contributing factors, What went well, What didn't, Action items.

Workflow

1. Reconstruct the timeline (UTC), one row per notable event
2. State impact in user-facing terms (requests failed, dollars lost, customers affected)
3. Identify the direct cause in one sentence — what specifically broke
4. List contributing factors (the conditions that made the incident possible / hard to mitigate)
5. Separate what went well (genuine wins, not platitudes) and what didn't
6. Owners + dates on every action item; hard fail if missing
7. Tone: blameless. Describe systems failing, not people.

References

• references/postmortem-template.md

Success criteria

• Every action item has an owner and a date
• Direct cause is one sentence
• No names attached to fault; only roles / systems
• Timeline times in UTC

Failure modes

• Missing source data → list gaps explicitly; don't fill with guesses
• Conflicting timelines → record both, flag for review