Root Cause Analysis Tool for IT Incidents
Five structured passes over your own incident evidence — is/is-not, fishbone, five whys, Pareto, change correlation — then a ranked list of causes and the gaps worth closing first.
- Ranked by evidence
- Five methods in one pass
- Runs in your browser
A root cause has to explain what was spared as well as what failed: if only the Riyadh branches lost card payments, the cause must explain why Jeddah didn't. This tool scores each candidate out of 100 on your evidence: is/is-not 35 points, change correlation 20, Pareto 20, five whys 15 and inversion 10. A change dated after the symptom is ruled out.
The symptom
When it was first seen. Every change you enter later is checked against this moment.
Candidate causes
Name what it might be, in any fishbone category, then answer what you actually know about each one. Blank answers are reported as gaps, not as no.
The inversion test
If you wanted to cause this deliberately tomorrow, how would you do it? Name the levers you would pull, then tick the ones that were really in place.
What the evidence supports
Updates as you type. Scores are out of 100 and only reflect what you have entered.
Frequency and impact are your figures. A candidate with no count and no impact carries no Pareto weight — it is not ruled out, it is just unmeasured.
How to get a usable answer
The ranking is only as good as the evidence behind it, so the tool scores how much you have answered separately from how strong the case is. A candidate at 30 points with every question answered is a weak cause; a candidate at 30 points with half the questions blank is an unexamined one. They need different work.
Work across the candidates rather than down one. Name four or five in different fishbone categories first, then answer the is/is-not pair for all of them, then the counts. Investigating one candidate to exhaustion before the others is how teams end up proving a favourite theory instead of testing it.
What each pass contributes
- Is / is not (35 points). Kepner-Tregoe. The strongest discriminator you have: a real cause explains the boundary as well as the failure.
- Change correlation (20). Most incidents follow a change. A change dated after the symptom is eliminated outright.
- Pareto (20). Frequency × impact, relative to the heaviest candidate, so effort lands on the vital few.
- Five whys (15). Depth reached without repeating yourself.
- Inversion test (10). The sabotage lever that turned out to be real.
Method & ownership
Five passes over evidence you supply: Kepner-Tregoe is/is-not (35 points), change correlation (20, with a hard elimination for any change dated after the symptom), Pareto by frequency × impact (20), five whys depth ignoring repeated answers (15), and an inversion test (10). No external data is used and nothing is stored.
The formulas used here are standard, published methods. The implementation, interface, wording, findings logic and benchmark figures are original work by ITSM Compass. Results are estimates, not professional advice. See the terms of use.
© 2026 ITSM Compass. All rights reserved.
Questions
Does this tool guess the cause for me?
No. It has no database of common causes and nothing is sent anywhere. It takes the candidates you name and the evidence you give for each one, applies five established techniques, and shows you which candidate the evidence actually supports — and which questions you have not answered yet.
Why does it keep asking what is NOT affected?
Because that is the question that separates causes. Plenty of explanations fit the failure; very few also explain why the sites, users or transactions that were spared were spared. A candidate that explains the failure but not the boundary is usually hiding a distinction nobody has looked at.
What is the inversion test?
You ask how you would cause the problem deliberately if you wanted to. Sabotage framing gets past defensiveness — people will happily describe a fragile approval step or a shared account they would never volunteer as their own team's fault. Any lever that turns out to have been in place becomes a candidate cause in its own right.
Why does a candidate get ruled out completely?
If you give a change date that falls after the symptom was first seen, the change cannot have caused it, whatever else it explains. That is the one hard elimination in the tool; everything else is weighted, not absolute.
How many whys should I get to?
Three to five. The tool counts depth but ignores any why that restates the previous answer, because that is where chains normally stall: the words change and the thinking does not.
Is my incident data stored anywhere?
No. It runs entirely in your browser, there is no account, and nothing is written to a server or to local storage. Close the tab and it is gone.
Causes keep coming back?
A problem management review finds the patterns behind repeat incidents and puts ownership on the fixes that stop them.