Download the root cause analysis template
The editable text worksheet contains a completed fictional investigation and a blank analysis form. The CSV supplies a small event timeline, evidence references, and limits on what each observation establishes. Both downloads are available without registration.
The exercise follows a repeated export-completion notification in a fictional SaaS called QueueNote. Every event, record ID, and outcome is invented teaching material. It is not a real customer incident or a report about ShowMeYourSaaS infrastructure.
Use the example to practice an investigation, then replace its facts with permitted evidence from your own system. Keep sensitive logs in their approved location and use references in the shared worksheet rather than copying tokens, private payloads, or customer files into it.
What is root cause analysis?
Root cause analysis, often shortened to RCA, is a family of methods for investigating the causes of a problem. ASQ describes approaches that include event analysis, change analysis, and examination of failed barriers. Choose a method that fits the available evidence and the question.
For a small SaaS, the question might be why one completed job produced two notifications, why a release exposed the wrong account, or why recovery took longer than expected. A useful investigation distinguishes the triggering event from the conditions that allowed it to produce harm.
An RCA can sit inside a postmortem. Google's SRE guidance describes a postmortem as a record of impact, response, causes, and follow-up work, with a focus on learning rather than blaming an individual. This worksheet concentrates on the causal reasoning and its verification.
Define the failure before choosing its explanation
The fictional problem statement is narrow: job J-204 produced two completion notifications for the same authorized workspace after one export. It identifies the observable result and the unit being counted. Customers got too many emails would leave the relevant event, destination, and scope unclear.
Record impact separately from evidence about the mechanism. Two notification records establish two recorded side effects; they do not establish that a human read both messages or that every workspace was affected. Keep those distinctions in the timeline and summary.
If the incident is active, prioritize the appropriate response plan and permitted containment. A retrospective worksheet should not delay urgent protection or replace specialist handling when access or data exposure may be involved.
Build a timeline with evidence and limits
In the exercise, the first worker completed the export and created notification N-501. Its acknowledgement was not recorded. A retry then ran for the same logical job and created N-502. Later, the operator disabled the affected notification path while checking the remaining jobs.
The CSV gives each observation an evidence reference. The missing acknowledgement is supported by the exercise's delivery record; the first completion and second notification are supported by distinct synthetic job and side-effect records. The order is useful, but sequence alone does not prove why the duplicate occurred.
Keep clock assumptions visible. The teaching timeline uses a single UTC clock. Real systems can have clock skew, delayed ingestion, and incomplete logs. When order is uncertain, record the uncertainty instead of forcing a precise chronology from timestamps that cannot support it.
| Observation | What it supports | What it does not establish |
|---|---|---|
| Export completion and N-501 recorded | First attempt produced a side effect | All downstream recipients read it |
| Acknowledgement absent in delivery record | Retry was eligible under the exercise policy | Why the acknowledgement was absent |
| Retry created N-502 for J-204 | Same logical job produced another side effect | A platform-wide incident |
Test competing causal explanations
One hypothesis is that the user requested two exports. Another is that a retry repeated the notification side effect. A third is that the mail provider duplicated one submitted message. The worksheet lists what evidence would support or contradict each explanation.
In the fictional records, the same logical job ID appears in two worker attempts and two application notification records. That favors the retry-side-effect explanation over two separate user jobs or a single provider submission duplicated downstream. It still leaves the missing acknowledgement's own cause unresolved.
The exercise also states that the notification path had no enforced uniqueness rule for logical job completion. That is a contributing condition to test, not a conclusion obtained merely by asking why several times. A five-whys discussion can generate questions; its chain needs evidence at each consequential step.
Do not stop at human error or worker retried. Ask which information, control, or system behavior made that action possible and consequential. Multiple conditions can interact, so a single neat root-cause sentence may hide useful distinctions.
Choose corrective actions that address the mechanism
The proposed primary action is an enforced unique completion key for the notification side effect. A second action adds a fixture in which completion succeeds, acknowledgement is lost, and the worker runs again. A third improves the view that connects attempts to logical jobs.
Assign an owner and verification method to each action. Write the observation that would demonstrate the intended protection: replaying completion for J-204 creates one notification, while a distinct authorized job can still create its own notification.
Disabling all completion messages could contain the immediate symptom but also remove legitimate functionality. Distinguish that temporary measure from a verified prevention change and record how ordinary service is restored. The SOP guide helps document the recurring operational steps.
Verify the fix and preserve remaining uncertainty
Run the relevant failure fixture in an authorized test environment. Exercise a replay, a normal new job, an interrupted attempt, and the actual permission boundary. A passing happy-path export alone does not test the duplicate mechanism.
Observe whether the corrective action changes the expected state, then record the evidence. The downloadable analysis labels its actions proposed because no application implementation was tested. Do not convert that teaching plan into a claim of incident resolution.
Retain open questions that matter, including why acknowledgement was absent and whether another side-effect path uses the same unsafe assumption. Some follow-up may become technical debt work, but each proposed repair should remain connected to the problem it addresses.
Keep the analysis useful after the meeting
Review overdue actions and check whether later incidents challenge the original explanation. A completed document without implemented and verified changes contributes little to preventing recurrence. Keep a dated owner and a review trigger with consequential decisions.
The blank template includes problem, scope, impact, timeline, hypotheses, supporting and conflicting evidence, contributing conditions, actions, verification, and unknowns. The two files were checked for matching evidence references and consistent fictional labels. Their consistency is not proof that the invented events happened.
Sources and original exercise checked October 28, 2026. Use the framework to make your investigation traceable and revisable as better evidence arrives.