Root cause analysis report template

TL;DR

• An RCA report has one job: make the same incident impossible, or at least much harder, next time. Everything else is supporting material.
• The core sections: summary, impact, timeline, root cause, contributing factors, what went well and badly, and action items with named owners and dates.
• Blameless is a discipline, not a nicety: reports that name culprits produce quieter engineers and hidden failures, not fewer incidents.
• “Root cause” is rarely singular. Write the deepest cause you can act on, plus the contributing factors that let it reach users.
• An action item without an owner and a date is a wish. Track them like any other work.

When to use this

Use this template after any production incident worth remembering: customer-visible outage, data at risk, an on-call page that took more than an hour to resolve, or anything where the team’s reaction was “how did that happen?” Write it even when the fix was easy; easy fixes with unexamined causes are how the same incident returns quarterly.

The format below is deliberately boring. A predictable structure means readers (including future-you, and the next engineer you hire) can find the timeline or the action items in any report in seconds.

The template

[Incident title: short, factual, e.g. “Checkout API outage, March 12”]

Status: [Draft / In review / Final] Date of incident: [date] Duration: [detection time to resolution time, total] Severity: [SEV1/2/3 per your runbook] Author: [name] Reviewed by: [names, date of review meeting]

1. Summary

[Two to four sentences, plain language, readable by a non-engineer. What broke, who was affected, for how long, and the one-line cause. Write this last.]

2. Impact

• Users affected: [number or percentage, and which segment]
• Functionality affected: [what users could not do]
• Duration of impact: [may differ from incident duration]
• Data impact: [none / delayed / lost, be precise; “no data loss” is a claim you must verify, not assume]
• Business impact: [e.g. support tickets, missed transactions, SLA credits, if known]

3. Timeline

All times in [timezone]. Include detection lag (when it started vs. when you noticed) honestly; it is often the biggest finding.

Time	Event
[HH:MM]	[First anomaly, in hindsight]
[HH:MM]	[Detection: alert fired / customer reported / engineer noticed]
[HH:MM]	[Incident declared, roles assigned]
[HH:MM]	[Key investigation steps and findings]
[HH:MM]	[Mitigation applied, impact contained]
[HH:MM]	[Full resolution confirmed against user-facing symptom]

4. Root cause

[The deepest cause you can act on. Ask “why” until the answer is a process, design, or safeguard gap rather than a person. “Engineer ran the wrong command” is not a root cause; “the production and staging CLIs are identical, with no confirmation prompt on destructive production commands” is.]

5. Contributing factors

[The conditions that turned a fault into an incident. Typically 2 to 4 items:]

• [e.g. The alert that should have caught this was muted since a noisy week in January]
• [e.g. The rollback procedure had never been tested against a migration]
• [e.g. Only one person knew the failover steps, and they were on a plane]

6. What went well / what went badly

Well:

• [e.g. Mitigation was fast once the right person was engaged]

Badly:

• [e.g. 40 minutes of the outage was spent finding database credentials]

7. Action items

Every item has an owner and a date. Split into “prevent recurrence” and “improve response.”

#	Action	Type	Owner	Due	Status
1	[e.g. Add confirmation prompt to destructive prod CLI commands]	Prevent	[name]	[date]	Open
2	[e.g. Un-mute and re-tune the queue depth alert]	Detect	[name]	[date]	Open
3	[e.g. Document and rehearse the failover procedure]	Respond	[name]	[date]	Open

Short filled example

Summary: On [date], background jobs stopped processing for 2h 10m, delaying customer email receipts and exports. No data was lost; all jobs completed after recovery. Cause: the job queue’s Redis instance filled its memory and began evicting keys, because a new feature enqueued jobs with unbounded payloads.

Root cause: Job payloads had no size limit, and Redis was configured with an eviction policy that silently drops data under memory pressure rather than refusing writes.

Contributing factors: No alert on Redis memory (only on CPU); the feature was load-tested with small accounts only; queue depth graphs existed but nobody looked at them because nothing paged.

Action items: cap payload size at 64KB, store bodies in object storage (owner: A.R., due in 2 weeks); switch Redis to noeviction and alert at 75% memory (owner: J.M., due this week); add queue depth to the paging alert set (owner: J.M., due this week).

How to use this

Copy the template, write the timeline first (it is the easiest section and anchors everything else), then work down to root cause by asking “why” past the first comfortable answer. Hold a 30 to 45 minute review meeting where the report is read, corrected, and the action items are accepted by their owners. Then, and this is the step most teams skip, check the action items at 30 days. A binder of unexecuted RCAs is how teams have the same incident twice.

Every fix Erzon ships comes with exactly this document: a written root cause report and a prevention list. If you have an incident you never got to the bottom of, send us the details; triage is free and the first response comes within one business hour.