Root cause analysis template

A root cause analysis identifies the specific condition or failure that, if removed, would have prevented the incident — as distinct from the symptoms you noticed and the contributing factors that made it worse or more likely. A root cause analysis template for IT incidents keeps those three things separate on the page, which is where most rushed analyses go wrong.

For example: a database ran out of connections (symptom), because a set of analytical queries held connections open too long (contributing factor), because no query timeout was enforced (root cause).

Not every incident needs a formal RCA. Run one when an incident is high-severity, repeats a previous failure, breaches an SLA, or is likely to recur without a specific fix. Minor, one-off issues with an obvious, already-fixed cause usually don't need the full exercise — noting the cause in the incident report is enough.

There's no single correct method — pick whichever fits the incident's complexity.

• Five Whys — ask "why" repeatedly, each time about the previous answer, until you reach a cause you can act on. Fast and simple; works best for straightforward, single-cause incidents.
• Fishbone (Ishikawa) diagram — group potential causes into categories such as people, process, technology, and environment. Useful when several factors likely combined to cause the incident.
• Fault-tree analysis — map the logical combination of failures that had to occur together for the incident to happen. Suited to complex systems with multiple failure paths.
• Change analysis — compare the system's state before and after the incident to isolate what changed. Effective when the incident followed closely after a deploy, config change, or migration.

The template below defaults to Five Whys, with a fishbone-style breakdown alongside it — switch or combine methods as the incident warrants.

Problem statement

A short, factual restatement of what failed — not the whole incident report. Link to it rather than repeating it.

Method used

Name the method (Five Whys, fishbone, fault-tree, change analysis) so anyone reading it later understands how the conclusion was reached.

The analysis

The actual reasoning — the why-chain, the categorized factors, the fault tree, or the before/after comparison. This is the part worth the most care; a rushed analysis tends to stop at the first plausible answer rather than the real one.

Trigger, root cause, and contributing factors

Separate three things: the trigger (the immediate event that started the incident — a deploy, a query, a config change), the root cause (the deeper condition that let it turn into an incident, described as a system or process — never a person or team), and contributing factors (conditions that made it more likely, longer, or worse, without being the trigger or the cause). Mark the root cause suspected or confirmed based on the evidence.

Corrective and preventive actions

Corrective actions fix what's already broken; preventive actions reduce the chance of recurrence or of a similar incident elsewhere. Every action needs an owner and, for high-priority ones, a due date.

Verification

Confirm the fix actually addresses the root cause, not just the symptom — and record how and when that was checked. An RCA that's never verified can quietly leave the real cause unresolved.

The following example continues the INC-2026-017 incident used in the incident report template.

RCA title: Why did the database connection pool get exhausted? Related incident: INC-2026-017 Method used: Five Whys Trigger: A batch of long-running analytical queries began holding connections open for several minutes each.

Five whys

Root cause

No query timeout was enforced on the shared connection pool, so long-running analytical queries could consume connections indefinitely. Status: Confirmed.

Contributing factors

• Analytical and customer-facing workloads shared the same connection pool.
• No alert existed for connection-pool saturation.

Corrective and preventive actions

Verification

Confirmed by load-testing the analytics workload against the new timeout and pool isolation; no connection exhaustion after two weeks of monitoring.

An RCA is usually one input to a postmortem, not a replacement for it — and it comes after the incident report, not instead of it.

See our IT incident report template for the record that feeds the RCA; the postmortem template is coming soon.

• Don't stop at the first plausible cause. Keep asking why until you reach something you can act on, not just something that sounds sufficient.
• Distinguish confirmed from suspected. Don't present a working theory as a verified conclusion.
• Involve people close to the work, not just the incident commander — they often know the "why" that isn't visible in logs.
• Separate the root cause from contributing factors. Fixing a contributing factor without addressing the root cause won't prevent a recurrence.
• Avoid blame. Ask what let the system fail, not who made the change.
• Verify the fix. Confirm it addresses the root cause, not just the immediate symptom.

What's the difference between a root cause and a cause?

A cause is anything that contributed to the incident. The root cause is the specific one that, if removed, would have prevented it — everything else is a contributing factor.

How many "whys" do you need?

As many as it takes to reach something actionable — often around five, sometimes fewer or more. Stop when the next answer is something your team can actually fix.

Does an RCA replace a postmortem?

No. The RCA explains the cause; the postmortem uses that analysis, plus the incident report, to document lessons and drive broader change.

Who should run the RCA?

Usually the incident owner or a nominated facilitator, with input from the people who were closest to the affected systems during the incident.

Define which severities require an RCA, who's responsible, and how findings feed into your postmortem and corrective actions — the same way you would for an incident report. Run consistently, an RCA turns each incident into a specific, verifiable improvement, not just a story about what went wrong.

The template draws on how teams with public engineering handbooks run their post-incident reviews. Notably, none of them prescribes an analysis method. What they standardize is the threshold, the deadline, the owner and where corrective actions live, and the template follows that.