Fault Tree Analysis 101 – A Comprehensive Guide

Equipment can fail for a number of reasons, but a common cause for failure is often because the real cause was missed and the same conditions were allowed to repeat.

Fault Tree Analysis (FTA) is a simple way to work backwards from a breakdown and map what had to be true for it to happen. You start with the failure (“top event”), then break it into the most likely contributing paths until you can see what to fix to stop the repeat.

For example, a critical conveyor drive keeps burning through bearings every few weeks. The repair is quick on paper (“replace bearing”), but the downtime is costly, and it keeps happening. An FTA forces the team to separate symptoms from causes (think contamination ingress, lubrication practice/spec, alignment, vibration/overload, and so on) and trace each one back to what’s driving it, so the fix isn’t just another replacement and ignoring underlying issues.

This guide shows how FTA is used after breakdowns to understand failure logic, prevent repeat issues, and improve maintenance follow-up.

Key takeaways

• • Fault tree analysis works backwards from a failure to reveal the conditions that allowed it to happen.
  • FTA organizes field findings; it does not replace inspecting, testing or troubleshooting the equipment itself.
  • A useful top event states what happened without guessing the cause before the analysis begins.
  • Basic events should be observable, verifiable and actionable, while failure logic shows how they combine to cause the bigger problem.
  • The analysis only creates value when its findings become better inspections, maintenance tasks and follow-ups.

What a Fault Tree Analysis is (and what it isn’t)

A fault tree analysis provides a structured way to think through failures.

It’s a method for mapping cause and effect when equipment doesn’t behave the way it should. You start with a clear problem, then work backward to understand what conditions had to exist for that problem to occur.

FTA is not:

• A root cause report template
• A reliability engineering exercise
• A replacement for troubleshooting in the field

If a guard is tripped, you clearly still need to check the switch. Fault tree analysis doesn’t replace that work (or common sense) - it organizes it. What FTA does well is let teams pause to think through a failure. It prevents jumping straight to the most obvious explanation or the last thing touched. It forces the question: what else had to be true for this to happen?

This is especially useful when:

• The same failure keeps coming back
• Multiple fixes have already been tried
• Different people give different explanations for what went wrong

At its core, fault tree analysis is just a disciplined way to document how small, everyday problems combine into a larger failure and which of those problems are worth fixing.

How a Fault Tree reads (events, logic gates, symbols)

A fault tree is read from the top down. The top event states the failure being investigated, while the branches underneath show the events that could have caused it. Between them sit logic gates, which explain whether one cause is enough or several conditions must occur together.

For example, “conveyor stopped” might sit above an ‘OR’ gate connected to power loss, drive failure and an open guard circuit. Any one of those events could stop the conveyor. A drive failure might then sit above an ‘AND’ gate if it requires both an overloaded motor and failed overload protection.

The symbols are not there to make the analysis look technical. They show how the causes fit together. A mechanic should be able to follow each branch, understand the logic and reach conditions that can be checked in the field.

Fault Tree Analysis - Step by step

Step #1 - Identifying the Top Event

Every fault tree starts with one problem, one specific failure that stopped work. The top event should describe what happened, not why you think it happened.

“Conveyor belt stopped” works.
“Electrical issue on the conveyor” does not.

Keeping the top event tight is important, as if it’s too vague, everything below it turns vague too. The goal is to anchor the analysis to something everyone on site agrees actually occurred.

Step #2 - Break the failure into Basic Events

Once the top event is established, the next step is to ask what had to go wrong for that event to happen. This is where teams move away from symptoms and into basic events. Basic events are small, concrete conditions. Things you can see, measure, or verify in the field.

Examples include:

• Motor overload tripped
• Belt misaligned
• Guard switch open
• Hydraulic pressure below setpoint

If a statement can’t be checked or proven, it’s not a basic event yet. Keep pushing until it is.

Step #3 - Figure out the Failure Logic

Not all failures happen the same way. Some top events occur when any one basic event happens. Others only occur when several things fail together. This relationship is the failure logic.

Understanding this logic is where fault tree analysis adds real value. It explains why a problem might only show up during certain shifts, weather conditions, or production rates. The failure logic also helps teams stop chasing single causes when the real issue is a combination of small misses stacking up.

Step #4 - Build the Fault Tree (keep it simple)

Building the fault tree means laying this logic out visually, from the top event down to the basic events. Start at the top. Work downward. Ask the same question every time:
What had to be true for this to happen?

Stop when you reach basic events that are:

• Observable in the field
• Verifiable with data or inspection
• Actionable through maintenance or process changes

If the tree starts turning into a theory exercise, it’s gone too far. A useful fault tree is simple enough that a mechanic or operator can read it and say, “Yes, that makes sense.”

Step #5 - Act on the Insights

The point of fault tree analysis is to turn basic events into specific changes in how work gets done. Each basic event should lead to at least one question: what can we change so this doesn’t happen again?

That might mean:

• Adding a check to a pre-shift or post-shift inspection
• Tightening a PM task that was too generic
• Adjusting inspection frequency on a known weak point
• Making a condition visible that used to be assumed

How to turn Fault Trees into better maintenance

Fault trees make sense only if they improve future work.

Each basic event should lead to a specific action – a clearer inspection, a tighter PM, or a condition that gets checked before it causes downtime. That only works if the insights don’t disappear into notebooks, spreadsheets, or someone’s memory.

When fault trees are captured in the same place as inspections, deviations, follow-ups, and maintenance actions, patterns start to show. Repeated basic events become visible. Missed checks stop being invisible. Improvements stick across shifts and crews.

That’s when fault tree analysis moves from a one-time exercise to part of everyday maintenance – reducing repeat failures instead of just reacting to them.