Three rankings of the same stops
Every downtime Pareto starts from the same stop log and a choice of what to add up.
- By frequency: count the stops for each cause. This shows what interrupts the line most often.
- By duration: add up the downtime minutes for each cause. This shows where the time went, and it is the chart most downtime reports lead with.
- By lost throughput: measure how much production the line would recover if the cause were removed. This shows what the stops cost at the end of the line. It can't be added up from the log, because it needs a model of the line.
Frequency vs duration on one stop log
The Bottling Line demo file that loads in the ReliaStats tools holds 6,000 stops across five machines and 36 interrupt codes. Rank its interrupts by count and by minutes and you get two different charts.
Computed from bottling-line-demo.csv (6,000 stops, 13,112.5 downtime minutes). Demo data, used here only to show how the two rankings differ.
| Interrupt | Stops (rank) | Downtime min (rank) | Mean stop | Stops over 10 min |
|---|---|---|---|---|
| Capper_Micro Stop | 1,345 (1) | 200.6 (17) | 0.15 min | 0 |
| Filler_Micro Stop | 967 (2) | 1,573.0 (3) | 1.63 min | 0 |
| Capper_Upper Plow Area | 865 (3) | 2,920.3 (1) | 3.38 min | 53 |
| Capper_Picker Tree Assembly | 701 (4) | 816.4 (4) | 1.16 min | 7 |
| Labeler_Misalignment | 326 (5) | 1,876.2 (2) | 5.76 min | 6 |
| Palletizer (no mode code) | 102 (12) | 644.8 (5) | 6.32 min | 17 |
Ranks are out of 36 interrupt codes in the demo file.
Capper_Micro Stop leads by frequency, with more than one stop in five, and comes seventeenth by minutes with 1.5% of the downtime. Capper_Upper Plow Area leads by minutes with 22.3%. Labeler_Misalignment is fifth by count and second by minutes, because its stops average 5.8 minutes against 0.15 for the Capper micro stop. Neither chart is wrong. They answer different questions.
What a frequency Pareto is good for
Frequent stops cost more than their minutes suggest. Each one is a restart, with whatever startup loss and operator attention a restart takes, and on a tightly coupled line a stream of short stops keeps buffers from refilling. Frequency is also where chronic problems show up: a cause that stops the machine again within a couple of minutes of each restart. The Interrupt Explorer's Pareto ranks causes by stop rate per 24 operating hours and puts the chronic stop rate beside it.
What a duration Pareto is good for
Minutes are the natural unit for availability, and long stops are the ones that outlast accumulation and reach the rest of the line. But a total mixes two kinds of problem. In the demo file, 53 of Capper_Upper Plow Area's 865 stops ran longer than 10 minutes, against 6 of Labeler_Misalignment's 326. A buffer that covers 10 minutes treats those two causes very differently, and the totals can't show it. Looking at the distribution of stop lengths for each cause, not just the sum, is the first step past the Pareto. The MTBF vs MTTR guide shows why.
Why the top duration bar may not be the top throughput loss
The chart that matters for a budget is the third one: what comes back if you fix it. Removing a failure mode doesn't simply hand back its downtime.
- Buffers absorb some stops. Downtime on a machine feeding a well-stocked buffer can cost almost nothing, because the next machine keeps drawing on stock.
- Some stops overlap with waiting. Part of the downtime happened while the machine would have been starved anyway.
- Some stops cascade. A stop that starves or blocks several other machines costs more than its own minutes.
- Position matters. The same minutes cost differently depending on where the machine sits relative to the constraint.
Loss/gain analysis measures this directly. In a validated model of the line, disable one failure mode, re-run the whole line and measure the production recovered, then repeat for each mode. In ReliaSim's methodology example on a bottling line, two failure modes lose almost the same share and return very different amounts:
| Failure mode | Loss | Gain when removed | Gain ÷ loss |
|---|---|---|---|
| Labeler Misalignment | 6.78% | 5.10% | 0.75× |
| Filler Micro Stop | 6.67% | 7.97% | 1.2× |
Published ReliaSim results from reliasim.com/method.html. They are not computed from the demo file above.
By loss, the Labeler mode is slightly ahead. By what comes back, the Filler micro stop returns more than it appeared to cost, while the Labeler mode returns about three-quarters of its loss. No ranking of downtime minutes could have told the two apart. ReliaSim's guide Which loss to fix first walks through the method, and the loss/gain analysis section of OEE improvement tradeoffs sets it beside the other levers.
From Pareto to root cause
A Pareto tells you where to look. Getting to root cause takes a few more cuts of the same data.
- Drill from machine to failure mode. "Capper" is not a failure mode. In the demo file the Capper alone stops for twelve interrupt codes, and each can have a different cause, a different fix and a different statistical shape.
- Deal with vague codes. The demo file has 102 stops coded only "Palletizer" and 49 coded only "Filler". The bare Palletizer code is fifth by minutes. When a generic code ranks that high, better coding is the first fix, because a real failure mode is hiding inside it.
- Look at timing, not just totals. Stops that follow closely on a restart point toward setup, adjustment or incoming material rather than a part wearing out. The Explorer's reliability window and survival curves show this for each cause.
- Look at shape. A distribution fitted to each mode's runs tells you whether stops are early-life, random or wear-out, and so whether time-based maintenance can help. See Weibull analysis of downtime data.
- Price the fix. Before committing budget, estimate what the line gets back, not what the bar lost. That needs a validated line model.
Methods such as 5 Whys or a fault tree still do the diagnosis. These steps point them at the right mode.
Build all three rankings with ReliaStats and ReliaSim
- Interrupt Explorer: load an .xlsx or .csv stop log for a Pareto by stop rate, with drill-down from place to mode, chronic stop rates and survival curves. It runs in your browser.
- ReliaStats desktop app: fit TTF and TTR distributions for each cause group and export them for ReliaSim, as part of a ReliaStats subscription.
- ReliaSim: build the line, validate each interrupt against history, then rank failure modes by recovered production. See OEE simulation.
For the full path from stop log to model, see downtime data analysis for production lines. For why a machine with good availability can still hurt the line, see availability vs reliability.
Frequently asked questions
What is a downtime Pareto chart?
A bar chart of downtime causes sorted from largest to smallest, usually with a cumulative line, so the few causes behind most of the loss stand out. It can rank causes by number of stops, by downtime minutes or by lost production.
Should a downtime Pareto use frequency or duration?
Both. Frequency shows what interrupts the line most often and where chronic re-stops are. Duration shows where the time went. In the demo stop log used in this guide, the most frequent cause is seventeenth by minutes.
Why doesn't fixing the biggest downtime bar give back all its minutes?
Buffers absorbed some of the stops, some happened while the machine would have been starved anyway, and others cascaded into other machines. The production recovered can be less or more than the downtime recorded.
How do you rank downtime by lost throughput?
With a validated model of the line. Remove one failure mode, re-run, measure the production recovered and repeat for each mode. ReliaSim calls this loss/gain analysis.
How do I find the root cause of downtime from a Pareto?
Drill from machine to failure mode, clean up generic cause codes, look at timing relative to restarts and at the spread of stop lengths, then investigate the modes that return the most production when fixed.
Where do the numbers in this guide come from?
The frequency and duration figures are computed from the Bottling Line demo file that loads in the ReliaStats tools. The loss and gain figures are published ReliaSim results from reliasim.com/method.html. Nothing on the page is a new simulation result.