Key points
- Root cause analysis (RCA) finds the condition behind a failure, not just the part that broke. Fix the root cause and the failure stops coming back.
- Six real root cause analysis examples below, each paired with the method that cracked it: the 5 Whys, Fishbone, and Fault Tree Analysis.
- The pattern: almost every "mechanical" failure traces back to a process gap, not a bad part.
- RCA gets faster and more accurate with condition data behind it, and Tractian customers have the downtime and cost savings to prove it.
Most maintenance teams already know what root cause analysis is on paper. The gap is almost never the definition. It is seeing what a real investigation looks like when the pressure is on, the line is down, and everyone in the room has a theory.
So instead of another textbook walkthrough, here are six real root cause analysis examples pulled from actual industrial equipment failures. Each one starts with a symptom that looked mechanical, follows the causal chain to where it actually terminated, and ends with the fix that made the failure stop. You will notice a theme by the third example: the broken part is rarely the real problem.
What Root Cause Analysis Actually Does
Before the root cause analysis examples, one quick frame. A failure shows up as a symptom: abnormal vibration, high temperature, an unexpected trip, rejected parts. The physical cause sits one level down (the bearing that seized, the seal that wore through). The root cause sits deeper still, at the decision or condition that let the physical cause happen in the first place.
Replace the bearing and you have treated the symptom. Update the procedure that caused four bearings to fail in a row and you have treated the root cause. That difference is the entire point of RCA, and it is why the same handful of methods keep showing up across every plant. You can read the full method breakdown on our root cause analysis glossary page, but the root cause analysis examples below will teach it faster.
Example 1: The Conveyor Motor That Kept Overheating
Method: 5 Whys
A conveyor belt drive motor failed without warning. The line stopped, the motor was hot, and the easy answer was "the motor is old, replace it." A quick 5 Whys said otherwise.
- Why did the motor fail? It overheated.
- Why did it overheat? Airflow to the cooling fins was blocked.
- Why was airflow blocked? Dust had built up on the motor casing.
- Why had dust built up? There was no cleaning task in the preventive maintenance schedule for this motor.
- Why was there no cleaning task? The motor was added during a production expansion and was never fully onboarded into the CMMS maintenance plan.
The root cause was not dust and it was not the motor. It was a gap in the asset onboarding process. The fix was to add the preventive maintenance schedule task and audit every recently installed asset for complete maintenance coverage.
The lesson: Some of your most reliable-looking equipment is quietly running with no maintenance plan at all, because it slipped through during a busy expansion. RCA finds those gaps before they find you.
Example 2: The Pump Seal That Died Every 60 Days
Method: 5 Whys
A centrifugal pump at a chemical plant handling a mildly corrosive fluid kept failing at the mechanical seal. Expected seal life was 18 months. Actual life was averaging 60 days. Each time, the crew replaced the seal and moved on, and each time it came back.
The 5 Whys unwound it:
- The seal was failing because of dry running.
- Dry running was happening because the automatic priming valve kept sticking closed.
- The valve was sticking because it had been specified for clean water service, not the corrosive process fluid.
- The valve had never been upgraded because there was no formal management-of-change (MOC) process requiring engineering review when a process fluid was changed.
The root cause was an organizational gap, not a mechanical one: no MOC procedure. The corrective action swapped in a chemically compatible valve and established a formal MOC checklist. Seal life returned to the full 18 months.
The lesson: When a component fails on a schedule this predictable, stop replacing it and start asking what changed upstream. A seal failing every 60 days is not a bad seal. It is a warning that something in the system was never updated when conditions changed.
Example 3: The Bearing That Was Replaced Four Times
Method: Fishbone (Ishikawa) Diagram
A 75 kW induction motor driving a mixer in a food and beverage plant had its drive-end bearing replaced four times in 18 months. Every replacement was logged as a routine corrective task. Nobody connected the dots until the failures were mapped on a Fishbone diagram across the standard categories.
Three branches lit up:
- Machine: the bearing fit tolerance was incorrect, allowing tiny movement in the housing.
- Method: the technician was seating bearings with a hammer instead of an induction heater, causing installation damage.
- Measurement: no vibration baseline was taken after installation, so a bad fit was never caught before the motor went back into service.
The root cause spanned two of those categories: an inadequate installation procedure plus the absence of post-installation verification. Updated procedures now specify thermal installation and a mandatory vibration analysis check after every bearing job. The result: the bearing ran for more than two years without a single replacement.
The lesson: Repeat failures on the same asset are the clearest RCA trigger there is. If you are replacing the same component more than twice a year, the problem is almost never the component. It is how the component is being installed, specified, or verified.
Example 4: The Servo Valves That Kept Failing on the Press Line
Method: Fishbone + 5 Whys
An automotive press line went through eight servo valve failures in a single quarter. Each valve was replaced under warranty, and each replacement had a short life. That warranty coverage was actually hiding the problem, because it made replacement cheap enough that nobody investigated.
Combining a Fishbone diagram with a follow-up 5 Whys pointed at hydraulic fluid contamination exceeding ISO 4406 cleanliness targets. The odd part: fluid sampled at the reservoir came back clean, while fluid at the valve block was heavily contaminated. That split is what broke the case open.
The return line filter element had not been changed in 14 months, against a 6-month requirement. Why? The filter change task had been entered into the CMMS as a quarterly item when the OEM specification called for it twice a year, and the interval had drifted from there. A single data-entry error in the maintenance plan was quietly starving the system of clean fluid.
Correcting the preventive maintenance frequency and adding a filter differential-pressure alarm resolved the contamination, and valve life returned to the OEM range.
The lesson: Your CMMS is only as good as the data in it. A mislabeled interval or a wrong frequency can generate a stream of "mechanical" failures that have nothing to do with mechanics. When two data points disagree (clean at the reservoir, dirty at the valve), that disagreement is your fastest path to the truth.
Example 5: The Press That Made Good Parts and Bad Parts
Method: Fishbone (Ishikawa) Diagram
Not every failure is a hard breakdown. A hydraulic press was producing inconsistent clamp force, and the bad parts were slipping through to assembly. There was no single obvious cause, which is exactly the situation the Fishbone diagram is built for. A cross-functional team mapped every plausible contributor:
- People: an operator skipping the warm-up sequence, and a technician calibrating the pressure gauge against the wrong reference standard.
- Machine: accumulator pre-charge pressure drifting, and seal wear developing between planned preventive maintenance intervals.
- Method: the maintenance procedure never specified how often to check the accumulator.
- Material: the hydraulic fluid viscosity grade had been changed during the last top-up without engineering approval.
The value here is not one dramatic root cause. It is that the Fishbone surfaced the full breadth of contributing factors so the team could test the most likely branches with a 5 Whys rather than guessing. Several small process gaps were compounding into a quality problem that looked random from the floor.
The lesson: When a failure produces quality escapes instead of a clean shutdown, resist the urge to chase one cause. Map the whole field first. Quality problems are usually the sum of several small drifts, and you cannot fix what you have not made visible.
Example 6: The Safety System That Did Not Trip
Method: Fault Tree Analysis
The highest-stakes root cause analysis example here involves a failure that, thankfully, was studied before it caused harm. An emergency shutdown (ESD) system failed to activate when a pressure vessel exceeded its safe operating limit. In oil and gas, chemical, and other high-consequence environments, "it usually works" is not an acceptable answer, so this called for Fault Tree Analysis (FTA).
FTA works from the top down. You define the top event (ESD fails to activate) and map every logical path that could produce it: sensor failure, an open circuit in the signal cable, a logic controller software fault, a solenoid valve mechanical failure, and the combinations of partial failures that could defeat the system together. By assigning failure probabilities at each branch, engineers pinpoint the weakest links and prioritize where to add redundancy or design changes.
The lesson: For safety-critical systems, RCA has to account for combinations of failures, not just single points. FTA is the right tool when the cost of being wrong is measured in people, not just downtime. It takes more skill than a 5 Whys, and for these systems it is worth every minute.
What These Root Cause Analysis Examples Have in Common
Read those six root cause analysis examples back to back and the pattern is hard to miss. The part that broke was almost never the actual problem:
- A dead motor was really a missing preventive maintenance task.
- A failing seal was really a missing management-of-change process.
- A repeat bearing failure was really an installation procedure and a skipped verification.
- Eight dead valves were really one wrong number in the CMMS.
- Bad parts were really several small process drifts stacking up.
- A silent safety system was really a set of weak links no one had mapped.
This is why "replace and move on" is so expensive. Every failure you close without root cause analysis is a failure you have agreed to see again.
Where Condition Data Changes the Game
Here is the part that ties directly back to why Tractian exists. Every one of these investigations depends on evidence: sensor trends leading up to the failure, complete work order history, a clear timeline of what changed and when. When that evidence is scattered across spreadsheets and memory, the investigation dead-ends at the symptom. When it is captured continuously, root cause analysis gets faster, more accurate, and often starts before the breakdown happens at all.
The results are not theoretical. Ingredion used Tractian's AI-powered condition monitoring to surface issues its team says it would never have caught otherwise, adding up to roughly $1.0M in production savings and 168 hours of avoided downtime at a single plant. Great Plains caught four critical failures in its first three weeks of monitoring. The Georgia Aquarium moved its team out of constant firefighting and into planned, proactive maintenance, keeping critical life-support equipment running around the clock.
That is what RCA looks like when it is backed by real-time data instead of teardown guesswork: you find the root cause once, prove the fix worked, and stop investigating the same failure twice. You can see how it works on our reliability and root cause analysis page, or browse more results on our case studies page.
The Bottom Line
Root cause analysis is not a form to fill out after a breakdown. It is the discipline that turns every failure into a permanent lesson instead of a recurring cost. As the root cause analysis examples above show, the method matters less than the follow-through: a plain 5 Whys acted on this week beats a perfect analysis that sits in a folder.
Start with your repeat offenders, the assets you are tired of touching. Pick the method that fits the problem, gather real evidence before anyone theorizes, and drive the corrective action all the way to a verified fix. Do that consistently and your maintenance program stops reacting to the same failures and starts getting measurably better with each one it investigates.
Ready to give your team the evidence to do root cause analysis right? See how Tractian condition monitoring works.
