Marine Root-Cause Analysis: From Symptom to Verified Solution

Most machinery faults on board get resolved the same way: something fails, it gets repaired or replaced, and the vessel moves on. Most of the time that's entirely correct — there's no need to investigate further when a straightforward repair holds. The problem is the minority of cases where it doesn't hold, and the same fault, or a close variant of it, comes back weeks or months later.

Root-cause analysis is simply the discipline of not stopping at the first plausible explanation.

Four different things that get called "the cause"

Part of what makes root-cause work difficult is that "cause" gets used loosely. It helps to separate four distinct things:

• The symptom — what was actually observed: a bearing failed, an alarm activated, a seal started leaking.
• The immediate cause — the direct physical mechanism: the bearing seized because it lost lubrication.
• Contributing factors — the conditions that allowed the immediate cause to occur: a blocked lubrication line, a slightly misaligned coupling adding load, a monitoring gap that meant the drop in lubrication wasn't noticed.
• The root cause — the underlying reason those contributing factors were present at all: a maintenance interval that doesn't match actual operating hours, a design assumption that no longer matches how the vessel is used, or a procedure that was never updated after an earlier modification.

A repair that addresses only the symptom and immediate cause — replacing the bearing — can look completely successful for a while. If the contributing factors and root cause are still in place, the same failure mode is still available to recur.

Why symptom-led repairs sometimes fail to hold

A failed component is a symptom. It's rarely the whole story. A bearing that fails prematurely might be a bearing quality issue — or it might be a symptom of misalignment, contamination, incorrect lubrication, or a vibration source entirely unrelated to the bearing itself. Replace the bearing without addressing whichever of those is actually responsible, and the replacement bearing is simply on the same trajectory as the one it replaced.

This is the pattern behind most "recurring fault" callouts: a competent repair was carried out, but to the symptom rather than the cause.

What a root-cause investigation actually involves

Establishing what's actually known, versus assumed

It's worth being explicit early on about what's confirmed by evidence and what's being assumed from experience or convenience. Useful evidence typically includes a clear timeline of events leading up to the failure, operating data from around the time it occurred, maintenance records for the component and the wider system, and a physical inspection of the failed parts before anything is discarded or cleaned up. Direct measurements — clearances, alignment readings, vibration levels, lubricant condition, electrical readings, whatever is relevant to the failure mode — carry more weight than a description of what someone remembers seeing. "It's probably the same as last time" does not count as evidence, even when it later turns out to be correct.

Looking for contributing factors, not a single cause

Failures are often the result of more than one factor combining, rather than one clean root cause. A system might tolerate slight misalignment fine on its own, and tolerate a slightly degraded lubricant fine on its own, but fail when both are present together. Treating either factor alone as "the" cause and fixing only that one can leave the underlying vulnerability in place.

The same discipline applies well beyond bearings. Recurring vibration can trace back to imbalance, resonance, coupling wear or a foundation issue, each of which produces a superficially similar symptom but needs a different fix. Hydraulic pulsation and noise is a good example of a fault that's frequently mis-attributed to the pump itself, when the actual cause is often an accumulator, air ingress or a pipework resonance downstream of it. A sensor fault can produce a control-system response that looks exactly like a genuine process problem, right up until someone checks whether the reading itself is actually correct. And a control-system interaction — two systems each behaving correctly in isolation, but producing an unwanted result once they're both live and responding to each other — can be mistaken for a fault in either individual system, when the fault only exists in the interaction between them.

Testing the explanation, not just proposing one

A plausible explanation isn't the same as a confirmed one. Where practical, a genuine root-cause investigation looks for a way to test the hypothesis — through inspection, measurement, or observing whether the fault behaviour changes when a suspected factor is corrected — rather than closing the investigation as soon as a reasonable-sounding cause has been proposed.

Considering the maintenance and operating context

The same physical fault can have a different root cause depending on how the vessel is operated and maintained. A failure that would be a simple wear-and-tear replacement on one operating profile might indicate a genuine design or maintenance-interval mismatch on another. This is why root-cause work often needs to look beyond the failed component itself, into how the system is actually being run day to day.

What this looks like in practice

A structured investigation typically moves through: understanding the operational context and history, gathering physical and documented evidence, identifying candidate causes and contributing factors, testing those candidates against the evidence, and only then proposing a corrective action — one that addresses the cause, not just the symptom that prompted the investigation.

Verifying the fix, not just assuming it

A corrective action is a hypothesis until it's actually been proven. The only reliable way to confirm a root cause has genuinely been addressed is to verify the fix under realistic operating conditions — not just a brief static test, but the same duty, load and operating pattern that produced the original failure. A repair that looks successful on a quick check, then fails again three months later under full load, hasn't actually been verified; it's simply had the same fault reappear on a longer timescale. Where practical, monitoring the corrected system for a period after the fix, against the same measurements used during the investigation, is what actually confirms the work has held — rather than assuming it has because the immediate symptom hasn't reappeared yet.

General principle versus a specific vessel's fault

The approach above is a general framework, not a diagnosis. Every vessel's machinery, maintenance history and operating pattern are different, and root-cause work has to be grounded in that specific context rather than applied generically. What it does mean is that a fault which has already resisted one or two repair attempts is usually a sign that the underlying cause hasn't yet been correctly identified — not that the equipment is simply unreliable.

This is the basis of Torven Marine's troubleshooting & investigations work — independent, evidence-led investigation rather than another round of symptom-led repair. It's also part of the wider independent technical consultancy we provide across a project, since the same evidence-based approach applies whether a fault has been running for years or has only just appeared during commissioning. If you have a fault that's recurred more than once, get in touch and tell us what's been tried so far.

Further reading

The same evidence-led thinking applies before a fault has even had the chance to recur: our article on why equipment can pass factory testing but still fail during vessel commissioning looks at why a component being technically compliant doesn't guarantee it will behave correctly once it's part of a complete vessel system.