DOWNTIME ANALYSIS

Using downtime Pareto to focus improvement effort.

A downtime Pareto ranks losses so teams can see which categories account for the greatest amount of lost production time.

Start with consistent categories

Downtime analysis becomes more useful when reason categories are clear enough for operators to use consistently and specific enough to support action.

Prioritise recurring loss

A Pareto helps separate frequent or high-duration problems from one-off events. The largest category is not automatically the easiest to solve, but it gives teams a rational place to investigate.

Move from category to cause

A reason such as “jam” or “material” may still be only the first level of explanation. Improvement work should combine the production record with observation and technical investigation before deciding on corrective action.

BUILD A USEFUL DOWNTIME PARETO

Rank losses by time first, then investigate the causes that repeat.

A downtime Pareto groups stopped time into consistent categories and sorts those categories from largest to smallest. That makes it easier to see whether a small number of recurring losses are consuming most of the available production time. The chart is useful because it directs attention; it does not prove the root cause by itself.

Reason quality matters. If one shift records “material shortage” while another uses “waiting”, the same operating problem can be split across categories and appear smaller than it really is. A short, well-defined reason list and consistent operator use normally produces a more actionable Pareto than a long list of overlapping codes.

FREQUENCY

How often does it happen?

Repeated short stops can consume significant time even when no single event appears serious.

DURATION

How much time is lost?

Rank cumulative downtime so teams can focus on losses with the largest production impact.

CONTEXT

Where and when does it occur?

Compare machine, shift, product and order context to find patterns hidden in the overall total.

FROM PARETO TO ROOT CAUSE

The downtime reason is the starting point for investigation, not the final answer.

A reason such as “breakdown”, “material shortage” or “changeover” describes what the operator observed. Root-cause work goes further by asking why the event occurred and what condition allowed it to repeat. Teams can then use maintenance history, process observations, quality data or structured problem-solving methods to test the suspected cause.

After an improvement is implemented, the same downtime history provides the verification step. Compare the frequency and duration of the targeted loss before and after the change, while accounting for production volume, product mix and planned time. The aim is to show that the loss actually reduced and stayed lower.

COMMON QUESTIONS

Frequently asked questions.

What is a downtime Pareto?

It is a ranked view of downtime categories, commonly ordered by total duration or event count.

Does a Pareto prove root cause?

No. It helps prioritise where to investigate; root-cause analysis still requires evidence and process knowledge.

RELATED CLEARRIVET SOLUTION

Downtime tracking software

See how ClearRivet applies this topic in a live manufacturing workflow with machine data, operator context and manager visibility.

Explore Downtime tracking software ↗

PUT THE CONCEPT INTO PRACTICE

Explore the production visibility capabilities behind the topic.

Move from the manufacturing concept into the practical software capabilities used to monitor production, understand downtime and keep teams focused on current losses.

See it. Then prove it.

Start with one machine for 14 days free.

Try the Live Simulator ↗