The Breakdown Did Not Happen by Chance: A Practical Guide to Fault Tree Analysis

Some breakdowns are simple.

A belt breaks. A sensor fails. A fuse blows. The technician replaces the part, tests the machine, and production resumes.

But some failures are not caused by one clear issue.

A machine may fail because several conditions came together at the same time. A weak inspection, wrong setting, poor cleaning, unavailable spare, missed alarm, and operator pressure may all contribute to the same breakdown.

In such cases, asking one “why” may not be enough.

That is where Fault Tree Analysis becomes useful.

Fault Tree Analysis helps maintenance teams work backwards from a failure and understand what combination of events or conditions allowed the breakdown to happen.

What Is Fault Tree Analysis in Maintenance?

Fault Tree Analysis, often called FTA, is a root cause analysis method used to investigate how a failure happened.

It starts with a main failure event and then breaks it down into possible causes below it.

In maintenance, the main failure event may be:

• Compressor tripped during production
• Conveyor stopped repeatedly
• Pump failed to deliver flow
• Boiler safety trip occurred
• Packaging line stopped due to sensor fault
• Critical motor overheated
• Hydraulic pressure dropped suddenly

The team then asks: what conditions could have caused this event?

Fault Tree Analysis is useful when the failure may have more than one contributing cause. It helps the team see whether the breakdown came from equipment condition, operating practice, maintenance gaps, spare quality, control system issues, environment, or a combination of these.

When Fault Tree Analysis Is Useful

Not every failure needs Fault Tree Analysis.

For simple problems, Why Analysis may be enough. But when the failure is serious, repeated, or unclear, Fault Tree Analysis can help the team investigate more carefully.

Use Fault Tree Analysis when:

• A critical asset fails
• Safety risk is involved
• The same failure keeps returning
• The cause is not clear
• Multiple systems are connected
• Several teams may be involved
• A failure created major downtime
• A customer, auditor, or management team needs evidence
• The problem may involve both technical and process causes

Fault Tree Analysis is especially useful for complex failures because it does not force the team to assume one cause too early.

Start with the Top Event

Fault Tree Analysis starts with the top event.

The top event is the failure you want to investigate.

A weak top event is:

Machine failed.

A better top event is:

Main conveyor stopped three times during the night shift due to motor overload trip.

The second version is better because it is specific.

It tells the team:

• Which asset failed
• What happened
• How many times it happened
• When it happened
• What failure condition was observed

If the top event is unclear, the whole analysis becomes weak.

The team should define the failure clearly before discussing causes.

Break the Failure Into Possible Cause Paths

After defining the top event, the team should break the failure into possible cause paths.

For example:

Top event: Conveyor motor overload trip.

Possible cause paths may include:

• Mechanical overload
• Electrical issue
• Control logic issue
• Material jam
• Incorrect operating condition
• Poor cleaning
• Wrong motor setting
• Weak inspection

Each path can then be broken down further.

For example:

Mechanical overload may come from:

• Belt misalignment
• Worn roller
• Material buildup
• Bearing seizure
• Incorrect belt tension

Material jam may come from:

• Product accumulation
• Bent guide plate
• Poor transfer design
• Cleaning residue
• Operator bypassing a sensor

This is where Fault Tree Analysis becomes useful. It helps the team see the full structure of the failure instead of jumping to one quick answer.

Look for Conditions That Combined Together

Many failures happen because more than one condition exists at the same time.

For example, a conveyor may not trip only because the belt was misaligned.

It may trip because:

• Belt was misaligned
• Material buildup increased load
• Motor overload setting was too low
• PM inspection did not check the transfer point
• Operator restarted the conveyor without reporting abnormal noise

Individually, each condition may look small.

Together, they create the breakdown.

Fault Tree Analysis helps maintenance teams see these combinations.

This is different from a simple one-line root cause. It shows how technical, operational, and maintenance gaps can join together to create a serious failure.

Use Evidence Before Building the Tree

Fault Tree Analysis should not be built only from opinions.

Before deciding possible cause paths, the team should collect evidence.

Useful evidence includes:

• Work order history
• Technician remarks
• Breakdown timestamps
• Alarm history
• Photos
• Sensor readings
• Operator observations
• Spare replacement history
• PM completion records
• Inspection findings
• Recent setting changes
• Vendor service history

A CMMS system helps because work orders, asset history, photos, readings, and corrective actions are easier to review when they are stored together.

Without evidence, the fault tree may look neat but still be wrong.

Fault Tree Analysis and Root Cause Analysis

Fault Tree Analysis is one method inside a broader root cause analysis process.

Root cause analysis asks: why did this failure happen, and what must change so it does not repeat?

Fault Tree Analysis helps answer that question by showing how the failure could have happened through different cause paths.

It is especially useful when the failure is not caused by one simple reason.

For example, if a motor trips repeatedly, the cause may not be only electrical. The fault tree may show mechanical overload, poor cleaning, incorrect setting, weak inspection, and operator restart practice as possible contributors.

That gives the team a better investigation path.

Fault Tree Analysis vs Why Analysis

Why Analysis and Fault Tree Analysis are both useful, but they are used differently.

Why Analysis is useful when the team can follow one clear chain of causes.

Fault Tree Analysis is useful when the failure may have multiple possible paths or combined conditions.

For example:

• Why Analysis asks: why did this happen, then why did that happen?
• Fault Tree Analysis asks: what possible conditions could have caused this top event?

In simple terms, Why Analysis goes deeper through one chain. Fault Tree Analysis maps wider cause paths under one failure event.

Both methods should still lead to practical corrective actions.

Fault Tree Analysis vs Fishbone Analysis

Fishbone Analysis helps the team group possible causes into categories such as machine, method, material, people, environment, and measurement.

Fault Tree Analysis is different because it shows the logical structure of how a failure event could occur.

Fishbone Analysis is useful for brainstorming possible causes. Fault Tree Analysis is useful for tracing how those causes could combine to create the failure.

In practice, a team may use Fishbone Analysis first to list possible causes, then use Fault Tree Analysis to map the most likely cause paths.

The method matters less than the outcome. The team must identify what needs to change.

A Practical Maintenance Example

Let us take a common case.

Top event: Packaging line stopped due to repeated conveyor motor overload trip.

Possible cause paths:

Mechanical load increased

• Belt misalignment
• Worn roller
• Bearing friction
• Product accumulation

Material flow problem

• Product jam at transfer point
• Bent guide plate
• Cleaning residue
• Wrong product size or weight

Electrical or setting issue

• Overload setting too low
• Loose connection
• Motor insulation weakness
• Control panel overheating

Maintenance control gap

• PM checklist did not include roller condition
• Transfer point was not inspected
• Previous abnormal noise was not converted into follow-up work
• Temporary fix was repeated

Operating condition

• Operator restarted without reporting issue
• Line speed increased
• Cleaning team did not report damage
• Production continued despite abnormal sound

Now the team has a clearer investigation path.

Instead of only resetting the motor, they can check the mechanical condition, material flow, overload setting, PM checklist, and reporting process.

That is the value of Fault Tree Analysis.

Convert the Fault Tree Into Corrective Work

A fault tree is not useful if it ends as a diagram.

Each confirmed cause or weak control should become action.

Actions may include:

• Corrective work order
• PM checklist update
• Inspection frequency change
• Spare replacement
• Setting correction
• Operator instruction update
• Cleaning checklist update
• Engineering modification
• Vendor follow-up
• Training action

This is where work order management software becomes important.

The team should not only identify the cause. They should create the corrective work, assign an owner, set a due date, and track completion.

Otherwise, the same failure can return.

Connect the Findings to Asset History

A serious failure should strengthen the asset history.

When the same asset fails again, the team should be able to see:

• What top event was investigated
• What cause paths were considered
• What evidence was captured
• What corrective actions were created
• Which actions were completed
• Whether similar failures happened before
• Whether the issue repeated after action

This is why Fault Tree Analysis should connect to asset management, not sit in a separate folder.

If the learning is not connected to the asset, the next technician or supervisor may repeat the same investigation again.

Fault Tree Analysis Should Help Reduce Repeat Failures

The real purpose of Fault Tree Analysis is to reduce repeated and serious failures.

If the same top event keeps happening, the team should ask:

• Did we define the top event clearly?
• Did we miss a cause path?
• Did we rely on assumptions?
• Did we verify the evidence?
• Did we assign corrective actions?
• Did we complete the actions?
• Did we check if the failure repeated?

For plants dealing with repeat failures, Fault Tree Analysis can help make the investigation more structured.

It gives the team a way to see the full picture behind a breakdown.

How MaintBoard Helps

MaintBoard helps maintenance teams keep the failure investigation connected to daily maintenance work.

Instead of keeping Fault Tree Analysis in a separate document, the team can connect the investigation with work orders, asset history, technician remarks, photos, readings, spare usage, and corrective actions.

With MaintBoard, teams can see:

• What failed
• When it failed
• What evidence was captured
• What possible causes were reviewed
• What corrective actions were assigned
• Who owns the follow-up
• Whether the action was completed
• Whether the same failure returned

A practical maintenance system should not only record that the machine was repaired. It should help the team understand why the failure happened and what changed after the investigation.

Final Thought

Fault Tree Analysis is useful when a failure is too serious or too complex for a quick answer.

It helps the maintenance team work backwards from the breakdown and understand the possible conditions that allowed it to happen.

The value is not in drawing a perfect tree. The value is in finding the weak controls, assigning corrective work, and preventing the same failure from returning.

If the machine is repaired but the conditions behind the failure remain unchanged, the breakdown can come back.

Fault Tree Analysis helps the team see those conditions more clearly.