What an Incident Report (Postmortem) Must Contain
The skeleton of an incident report is its overview. Write the title so both cause and symptom are visible ("Order failures caused by payment API latency"), then record the affected system, the severity, and the author. Severity is commonly graded P1 (full outage) through P4 (minimal impact); a clear grade determines reporting lines and response priority. Recording three timestamps — occurred, detected, resolved — yields total downtime (occurred→resolved) and time-to-detect (occurred→detected). A long time-to-detect is itself a finding: it means you have a monitoring gap.
The timeline is the report's core evidence. Pairing timestamps with events ("14:05 pool exhaustion begins → 14:12 threshold alert → 14:30 candidate cause identified → 15:00 rollback → 16:20 recovery confirmed") makes response bottlenecks visible at a glance — was the alert late, or did diagnosis take too long? Impact should be split into affected users/features and business impact (revenue loss, support volume) so that executives and engineers can read the same document.
A good report separates the direct cause from the root cause. The direct cause is the technical trigger ("long-running batch transactions exhausted the connection pool"); the root cause is the structure that allowed it ("batch and online workloads shared resources with no isolation, and no pre-deploy impact review existed"). Actions likewise split into temporary fixes (firefighting) and permanent fixes (structural change), and every prevention item needs an owner and a due date — otherwise it never ships.
This generator provides that structure as a form: downtime is calculated automatically from your timestamps, and timeline entries are auto-sorted by time. Everything stays in your browser, so internal incident details never leave your machine. The finished report — severity badge included — can be copied as Markdown for wikis and Notion, copied as plain text for email, downloaded as .md, or printed to PDF.