Incident Report
A blameless incident report that produces actual fixes — timeline, contributing factors rather than a single cause, and actions with owners and dates.
No sign-up. No email. Markdown — edit it in anything.
When to use it
After any incident affecting customers, data or availability.
Who fills it in
Incident lead, within 5 working days.
Works alongside: SOP · Release Checklist · Security Checklist
The template
Instruction lines are marked with > — delete them
once the document is filled in.
| Incident ID | |
| Date | |
| Severity | Critical / High / Medium / Low |
| Duration | ___ from detection to resolution |
| Customers affected | |
| Data affected | |
| Incident lead | |
| Status | Open / Resolved / Closed |
Blameless. The goal is a system that fails less, not a person to blame. People act reasonably given the information they had; if the outcome was bad, the system let them.
1. Summary#
Three sentences a non-technical executive can follow. What broke, who was affected, whether it is fixed.
2. Customer impact#
What customers experienced:
How many:
For how long:
Was data lost, exposed or corrupted?
Was anyone notified? When, by whom?
3. Timeline#
Facts with timestamps. Include when you thought something was true and later found it was not — that gap is usually where the real lesson is.
| Time | Event | Source |
|---|---|---|
| Change deployed / condition began | ||
| First symptom occurred | ||
| Detected — how? | ||
| Escalated to | ||
| First mitigation attempted | ||
| Root cause identified | ||
| Resolved | ||
| Monitoring confirmed stable |
Time to detect: ___ Time to mitigate: ___ Time to resolve: ___
If time-to-detect is long, that is a finding in itself.
4. What happened#
The technical narrative. Enough that a colleague could follow it without having been there.
5. Contributing factors#
Not "the root cause". Incidents in real systems have several. Listing one encourages a single narrow fix that leaves the others in place.
| # | Factor | Category |
|---|---|---|
| 1 | Code / Config / Process / Monitoring / Dependency / Documentation | |
| 2 | ||
| 3 |
Why did our defences not catch it?
- Testing:
- Review:
- Monitoring:
- Alerting:
6. What went well#
Genuinely worth recording — it tells you which controls to keep investing in.
7. What made it worse#
Slow detection, missing runbook, unclear ownership, a rollback that did not work, an alert nobody saw.
8. Actions#
Every action has one named owner and a date. "The team" is not an owner. An action without a date does not happen.
| # | Action | Prevents recurrence / Reduces impact / Improves detection | Owner | Due | Status |
|---|---|---|---|---|---|
| 1 | |||||
| 2 |
9. Follow-up#
| Review meeting held | |
| Attendees | |
| Report circulated to | |
| Actions verified complete on |
Severity guide#
| Severity | Definition |
|---|---|
| Critical | Core business function unavailable, or data lost/exposed. All hands. |
| High | Major function degraded, or a workaround exists but is painful. |
| Medium | Limited impact, acceptable workaround. |
| Low | Minimal impact, no urgency. |