What is a root cause analysis template?

A root cause analysis template is a reusable document structure for investigating why something failed and deciding what to change so it does not happen again. It fixes the order of the investigation: what happened, who it affected, the timeline, the trigger, the underlying cause, why it was not caught, the corrective actions, and who needs to be told. The template matters because RCAs written without one tend to stop at the first plausible explanation and skip the actions, which is what makes them feel like paperwork.

What should a root cause analysis template include?

Eight sections cover almost every case: a plain summary of what happened, the measured impact, a timestamped timeline, the trigger, the root cause with evidence attached, the detection and prevention gaps that let it through, a list of corrective actions with named owners and due dates, and the customer communication step. The two sections teams most often leave out are the detection gap and customer communication, and they are the two that decide whether the RCA changes anything.

What is the difference between a trigger and a root cause?

The trigger is the event that set the failure off, such as a deploy, a traffic spike, or a specific input. The root cause is the condition that made that trigger capable of causing harm, such as an unbounded query, a missing constraint, or a test suite that never covered the path. Triggers are easy to find and nearly useless on their own, because the next failure will have a different trigger. Fixing the condition is what prevents recurrence, so a root cause analysis that names only the trigger has not finished.

What is the difference between the 5 Whys and a fishbone diagram?

The 5 Whys follows one causal chain backward, asking why at each step until you reach a condition you can actually change. It is fast and works well when the failure has a single clear line of causation. A fishbone diagram, also called an Ishikawa diagram, branches instead, grouping candidate causes by category so you can compare several contributing factors at once. Use the 5 Whys by default and switch to a fishbone when the failure has more than one contributing cause, because forcing a multi-cause failure into a single chain produces a confident and wrong answer.

What is the difference between a root cause analysis and a postmortem?

They overlap heavily and many teams use the words interchangeably. In practice a postmortem is the meeting and the written record that follows a specific incident, usually an outage, and it covers response quality as well as cause. A root cause analysis is the causal investigation itself, and it applies to anything worth understanding, including a recurring bug, a process failure, or a quality problem that never caused an outage. The template here works for both, since the postmortem is essentially an RCA with the response timeline given more weight.

When should you run a root cause analysis?

Run one when the failure was severe, when it recurred, or when nobody can explain it. Severity alone is not the only trigger, because a small bug that has now returned three times is telling you something a single large outage might not. Skip the formal RCA for one-off issues with an obvious and already-fixed cause, since running the process on everything is the fastest way to make the team stop taking it seriously. The goal is a small number of RCAs that actually produce changes, not a complete archive.

Root Cause Analysis Template (Free, Copy & Paste)

Most root cause analyses fail in the same place. Not at the start, where someone writes a careful summary of what broke, and not at the end, where the document gets filed. They fail in the middle, at the moment someone offers the first explanation that sounds right and everyone in the room relaxes. The deploy caused it. The customer sent bad data. The queue backed up. Each of those is true and none of them is a root cause, and a week later the same class of failure comes back wearing a different hat.

A template does not make you a better investigator. What it does is refuse to let the investigation end early, by asking for the sections most people skip when they are tired and want the meeting to be over. This guide gives you that template, the three methods for filling in the hardest section, a worked example, and an honest account of when running one is a waste of everyone's afternoon.

In this article

Key takeaways

A root cause analysis template exists to stop the investigation from ending at the first plausible answer. Eight sections, in a fixed order, do most of that work.
The trigger is not the root cause. The trigger is what set the failure off, the root cause is the condition that let the trigger do damage, and only the second one prevents a recurrence.
Corrective actions without a named owner, a due date, and a tracked ticket are not actions. They are a list of intentions that expires the day the document is filed.
The two sections teams skip most are the detection gap and customer communication, and they are the two that decide whether the analysis changed anything outside the document.
Run RCAs on the severe, the recurring, and the unexplained. Running one on everything is the fastest way to make the team stop reading them.

8sections in the template

3methods for finding the cause

2sections almost everyone skips

What Root Cause Analysis Actually Is

Root cause analysis is the work of tracing a failure backward from the symptom people noticed to the condition that made the symptom possible. The definition sounds obvious. The difficulty is entirely in knowing where to stop, because every cause has a cause behind it and the chain does not naturally terminate.

The practical stopping rule is this: you have reached the root cause when you arrive at something you can change, and changing it would have prevented this failure and others like it. Stop earlier and you get a fix that addresses one instance. Keep going past that point and you end up at conclusions like "we were understaffed" or "the codebase is old", which may be true but do not convert into anything anyone can do on Tuesday.

The trigger is what happened. The root cause is what made it possible for that to matter. Fixing the first one buys you nothing, because the next failure will have a different trigger.

That distinction is worth being pedantic about, because it is where most analyses go wrong. A deploy that broke checkout is a trigger. The root cause is whatever let a change reach production without anything catching that it broke checkout. Deploys will keep happening. The gap is the part you can close.

The Root Cause Analysis Template

Here is the structure. Eight sections, in this order, because the order does real work: impact before cause keeps the team honest about whether this is worth investigating at all, and the timeline before the trigger stops people from naming a cause before they have laid out the facts.

1
1. What happened
Two or three sentences in plain language, written so that someone outside the team understands it. No jargon, no cause, no blame. If you cannot summarize the failure without explaining the architecture, you do not understand it well enough yet to analyze it.
2
2. Impact
Who was affected, how many, for how long, and what it cost in revenue, SLA exposure, or trust. Use numbers, not adjectives. This section is what tells a reader six months from now whether the corrective actions were proportionate, and it is what justifies the engineering time the actions will consume.
3
3. Timeline
Timestamped events in one timezone: first occurrence, first detection, escalation, mitigation, resolution. The gaps between those rows are usually more interesting than the rows. A four-minute failure that took nine hours to detect is a detection problem, not a reliability problem, and only the timeline shows you that.
4
4. Trigger
The specific event that set it off. A deploy, an input, a traffic pattern, a config change, an expired credential. Name it precisely and then keep going, because this is the section people mistake for the answer.
5
5. Root cause
The condition that made the trigger capable of causing harm, with evidence attached. A log line, a query plan, a diff, a graph. An RCA where this section is a paragraph of reasoning with nothing to point at is a hypothesis, and it should be labeled as one until someone confirms it.
6
6. Why it was not caught
Two gaps, considered separately. The detection gap is why nobody knew until a customer told you. The prevention gap is why the change reached production at all. Most teams write one sentence covering both, and lose the more valuable of the two findings in the process.
7
7. Corrective actions
Each action gets an owner by name, a due date, and a link to the ticket where it is tracked. An action without all three is not an action. It is an intention, and it expires the moment the document is filed.
8
8. Customer communication
Who reported this, who else was affected, and whether they have been told what changed. This is the section that most often does not exist, and it is the one that determines whether the customer who found your bug ever learns that you fixed it.

The Three Methods for Finding the Cause

Section five is the hard one, and there are three standard ways to work it. They are not competing philosophies. They suit different failure shapes, and picking the wrong one produces a confident answer that happens to be incomplete.

The 5 Whys, for single-chain failures
Ask why the failure happened, then ask why that happened, and repeat until you reach a condition you can change. Five is a rule of thumb, not a quota. The method is fast, needs no preparation, and works genuinely well when causation runs in one line. Its weakness is that it assumes a single chain exists, so on a failure with several contributing factors it will happily walk you down whichever branch you noticed first and present it as the answer.
The fishbone diagram, for multi-cause failures
Also called an Ishikawa diagram. Instead of following one chain backward, you branch: list candidate causes grouped by category, such as code, configuration, process, tooling, and people, then evaluate them together. It takes longer and needs a whiteboard or a doc, but it is the right tool the moment you suspect more than one thing had to go wrong simultaneously. Most serious outages are this shape.
The timeline walk, for failures nobody understands yet
When you cannot even state a hypothesis, stop trying to reason backward and reconstruct forward instead. Lay out every event in order from logs, deploys, alerts, and tickets, then look for the first moment the system was in a state you did not expect. This is slower than the other two and it is often the only one that works on an intermittent failure.

The default should be the 5 Whys, with one check: before you accept the chain, ask whether any single link could have failed without causing the outcome. If yes, something else was required too, and you have a multi-cause failure that deserves the fishbone. That one question catches most of the cases where the fast method would have given you a tidy and wrong answer.

A Worked Example

Abstract templates are easy to agree with and hard to use, so here is the same eight sections filled in for an ordinary failure, the kind that is far more common than a dramatic outage.

What happened. For roughly nine hours, customers on annual plans who updated their billing address received a validation error and could not save the change. Customers on monthly plans were unaffected.

Impact. Fourteen accounts hit the error, three of them filed tickets, one was mid-renewal. No revenue lost, but the renewal conversation got harder. Duration was nine hours and ten minutes from first occurrence to fix.

Timeline. Deploy at 08:20. First failed save at 08:34. First customer ticket at 11:05. Support reproduced it at 14:50. Escalated to engineering at 15:10. Fix deployed at 17:30.

Trigger. A deploy that tightened postal code validation to a stricter pattern.

Root cause. The stricter pattern rejected a format that only annual-plan accounts could produce, because that path stored the field with a legacy prefix that the new validator did not allow. The validator was correct in isolation. Nothing owned the fact that two writers used different formats for the same field.

Why it was not caught. Detection gap: no alert exists on validation error rates, so the first signal came from a customer nearly three hours in. Prevention gap: tests covered the monthly path only, because the legacy annual format was not represented in any fixture.

Corrective actions. Add an alert on validation error rate by endpoint, owner named, due in one week, tracked as a ticket. Normalize the legacy prefix at write time, owner named, due in two weeks, tracked as a ticket. Add annual-plan fixtures to the billing test suite, owner named, due in one week, tracked as a ticket.

Customer communication. All fourteen affected accounts identified from the error logs. The three ticket reporters received a direct reply confirming the fix. The mid-renewal account got a call.

Notice what the example shows about the timeline. The failure lasted nine hours, but the fix took twenty minutes once engineering had a reproducible case. Six and a half of those nine hours were detection and handoff. That finding lives in section three, and it points at a completely different set of corrective actions than the ones you would write from section five alone.

Where the Input Data Comes From

The reason RCAs get written badly is rarely that the team lacks analytical ability. It is that reconstructing section three takes hours, because the evidence is scattered across a support inbox, a chat thread, an issue tracker, and someone's memory of a call.

An RCA that is cheap to write

First report timestamp is on the ticket
The escalation is a linked issue with a time on it
Reproduction steps were captured at intake
The affected accounts are queryable
Resolution time is on the same record as the report

An RCA that costs a day

First report is somewhere in an inbox
The escalation was a Slack message nobody can find
Repro steps were reconstructed from a phone call
Affected accounts are reconstructed from memory
Resolution time has to be inferred from a deploy log

That difference is not about discipline during the incident, when nobody has spare attention. It is about whether the systems you already use record the handoff as it happens. If a customer-reported defect exists as a support ticket linked to a tracked engineering issue, with timestamps on both and the conversation attached, section three writes itself and section eight has a list of exactly who to contact. If the escalation lived in a chat thread, both sections are archaeology.

This is the same argument the bug tracking template makes about intake, one step later in the lifecycle. That template captures the report well enough to act on. This one captures the resolution well enough to learn from. They are two ends of the defect management process, and the middle of that process, the bug triage step, is where the timestamps that make an RCA cheap either get recorded or get lost.

For teams where support runs on HubSpot Service Hub and engineering runs on Linear, IssueLinker is what keeps that record intact. A triaged ticket becomes a linked Linear issue in one click with the customer conversation and reproduction context carried over, and when the issue closes the ticket updates, so the report time, the escalation time, and the resolution time all sit on connected records instead of in three different tools. When you sit down to write section three, the timeline is already there. The Linear HubSpot integration guide covers how the sync works.

Stop reconstructing your incident timelines from Slack

If support runs on HubSpot Service Hub and engineering runs on Linear, IssueLinker links the customer ticket to the engineering issue and keeps status flowing both ways, so the report time, escalation, and resolution all live on connected records when it is time to write the analysis.

Mistakes That Make an RCA Worthless

Four patterns account for most documents that get written, filed, and never referenced again.

Stopping at the trigger
The deploy broke it, the fix was to roll back, done. This produces a document that is accurate and useless, because rolling back is a mitigation, not a corrective action. If the analysis contains no change that would have prevented the failure, the analysis is not finished.
Corrective actions with no owner
"We should add monitoring" is not an action. Nobody owns it, nothing tracks it, and by the next incident it will be written down again in identical words. The test is whether each item in section seven exists as a ticket somewhere with a person's name on it. If not, delete it from the document, because a false record of intent is worse than an honest gap.
Writing it too late
The reconstruction gets harder every day. Logs age out, chat threads scroll away, and the person who found the issue stops remembering the order things happened in. Write the first draft within a couple of days while the detail is still recoverable, then revise. A rough RCA written on Thursday beats a polished one attempted the following month.
Running one on everything
The fastest way to make a team ignore RCAs is to require one for every bug. Reserve them for failures that were severe, that recurred, or that nobody can explain. The recurrence criterion is the one people forget, and it is the most valuable, because a small bug returning for the third time is a clearer signal about your process than a single large outage.

The underlying test for all four is simple. An RCA earned its cost if something is measurably different afterward: an alert that did not exist, a test that now covers the path, a customer who heard back. If nothing outside the document changed, the exercise was documentation, not analysis.

Copy-Paste Root Cause Analysis Template

Here is the template in plain text. Paste it into a doc, a Notion page, a ticket, or wherever your team keeps these. Cut a section if your team genuinely does not use it, and add one only when a missing section costs you a decision.

ROOT CAUSE ANALYSIS

Title:
Date:
Owner:
Severity: [ Critical | High | Medium | Low ]
Status: [ Draft | Under review | Closed ]

1. WHAT HAPPENED
Plain-language summary, 2 to 3 sentences:


2. IMPACT
Who was affected:
How many:
Duration (first occurrence to resolution):
Revenue or SLA exposure:

3. TIMELINE (one timezone, state which)
  --:--  First occurrence
  --:--  First detected, by whom
  --:--  Escalated to
  --:--  Mitigated
  --:--  Resolved

4. TRIGGER
The specific event that set it off:

5. ROOT CAUSE
The condition that made the trigger capable of causing harm:

Evidence (log line, diff, query, graph):

Confidence: [ Confirmed | Hypothesis ]

6. WHY IT WAS NOT CAUGHT
Detection gap (why we did not know sooner):

Prevention gap (why it reached production):

7. CORRECTIVE ACTIONS
  #  Action                    Owner        Due         Tracked as
  ------------------------------------------------------------------
  1.
  2.
  3.

8. CUSTOMER COMMUNICATION
Reported by:
Others affected:
Told what changed:  [ ] Yes  [ ] No  [ ] N/A

Use it as a starting point rather than a standard. The order is the part worth keeping, because it is what stops the analysis from finishing at section four. Everything else should bend to how your team actually works. And if you get through a whole RCA and section seven is empty, that is a real result too. It means the failure was genuinely unpreventable at reasonable cost, which is worth writing down explicitly so nobody re-litigates it in six months.

Root Cause Analysis Template: The Eight Sections That Matter