How to build a downtime Pareto from real minutes

You rank downtime reasons by the hours they cost by adding up the minutes of every stop under its reason, sorting the totals from largest to smallest and drawing a running cumulative percentage over them. That chart is a downtime Pareto. The first two or three bars, before the cumulative line flattens, are where an hour of improvement work returns the most.

This guide is for plant managers and maintenance leads. It builds one week of stops into a Pareto by hand, then shows how to drill into the leading bar and compare periods fairly. To decide which reasons to log in the first place, see which downtime reason codes to log.

What a downtime Pareto shows#

The IoTFlows docs define the same chart in the glossary. A stop log is the list it is built from: one row per stop, with the machine, start, end and reason.

Joseph Juran named the principle behind it after the economist Vilfredo Pareto, and coined the terms “vital few” and “useful many” for the two ends of the ranking.^[1] The 80/20 split is a shape, not a law. In the Juran Institute guide's own examples, the vital few carry anywhere from 65% to 86% of the total.^[1]

Count, minutes or cost: what should you rank by?#

Rank by minutes. A Pareto by count answers “what interrupts us most often”, which favors short pauses, since they happen dozens of times a shift. A Pareto by minutes answers “what takes the most capacity”, which is the question a plant manager asks.

For example, one week on six CNC machines produced 281 stops. By count, Short downtime leads with 186 stops. By minutes, Changeover leads, and Breakdown moves from last place to third.

Each measure answers a different question, so pick the one that matches yours:

Weight by cost only when a minute on one reason costs more than a minute on another. A weighted Pareto can point at different problems than a count-based one: in Minitab's clothing example, a defect type that made up 9% of defects was the second most costly.^[3] The same thing happens with downtime when one reason also burns parts or outside labor.

Keep the cost view as a second chart. Its rates are estimates, and the minutes view is the one everyone can check against the stop log.

To set a rate per reason, see how to rank downtime reasons by dollars.

Build the Pareto from a stop log#

You need one row per stop, with a duration and a reason. Any monitoring system or a paper log typed into a spreadsheet will do, as long as the minutes come from the clock and not from memory.

1. Fix the window and the machines

   Pick the date range, the shifts and the machines before you look at any numbers. For ranking, use four weeks or more; the worked example uses one week so the arithmetic stays short.

2. Export one row per stop

   Each row holds the machine, start, end, duration and reason. If your stops come from IoTFlows, the Downtimes CSV carries these columns, with the duration in seconds.

3. Clean the rows

   Fix spellings, clip stops at the window edges and split stops that hold two reasons. The rules are in the next section.

4. Sum the minutes per reason

   A pivot table that sums duration by reason does it in one step. In a formula, =SUMIFS(F:F, G:G, A2)/60 sums column F (seconds) for the reason in A2 and converts it to minutes.

5. Sort and add the cumulative share

   Sort the totals from largest to smallest. Divide each by the total stopped minutes, then keep a running sum of those shares down the list.

6. Draw the bars and the line

   Draw the minutes as bars against the left axis and the cumulative share as a line against a right axis from 0% to 100%.

Clean the stop log first#

A Pareto is only as honest as the rows under it. Check these before you sum anything:

• Sort on seconds, not on formatted text. A text duration such as 9m 12s sorts above 1h 4m in a spreadsheet.
• Clip stops at the window edges. A stop from 23:00 Sunday to 01:30 Monday puts 60 minutes in last week and 90 in this one.
• Decide where an overnight shift's minutes land. Charge a shift that crosses midnight to the day it began or split it at midnight, and use the same rule every week. IoTFlows calls the first choice shift islands.
• Split a stop that holds two reasons. A 90-minute stop where a changeover ran into a breakdown at minute 30 is 30 minutes of Changeover and 60 of Breakdown. Split the downtime at the minute the reason changed.
• Merge spellings of one reason. Matl late, No material and Waiting for material are one bar, not three short ones.
• Keep Unclassified as its own bar. Never spread its minutes across the other reasons in proportion. That hides how much of the chart is a guess.

A worked week on six CNC machines#

Where do the vital few end?#

Read the cumulative line, not the 80% mark. The vital few end where the line's slope flattens, which is how Juran reads the chart.^[1] In the worked week, each of the first three bars adds 15 to 32 points. From the fourth bar on, each adds 12 points or fewer, and the chart flattens.

Sometimes the line has no clear break, and Juran calls the bars around the bend the awkward zone.^[1] In the worked week the bend is gentle: Breakdown adds 15.3 points and Short downtime 11.6, so both sit near it. Put a bar from that zone in the vital few only when someone can act on it this month.

So three reasons out of eight carry 67.8% of the stopped minutes. That isn't 80/20, and it doesn't need to be. Act on those three, give each one an owner and a date, and leave the useful many for later.

Four bars change how you read the rest:

Minitab gives the same advice for any Pareto that isn't useful: make sure the categories are meaningful and that Other isn't too large.^[2]

Short downtime needs a second look because it is one code for hundreds of stops. In the worked week it holds 186 stops averaging 2.5 minutes. Vorne describes minor stops as usually well under five minutes and not needing maintenance staff.^[4]

Split the code by machine to see where they cluster before you give it an owner. Where the short-stop cutoff sits decides how many stops land in this bar, see how to set the short-stop cutoff.

Drill into the leading bar#

A reason on the Pareto is a starting point, not a cause. The next move is a second Pareto of the leading reason's minutes, split by another factor. Juran's guide lists ways to classify the data that can reveal a vital few, among them type, time of day, week or month, and the place where the work is done.^[1] For downtime, place means the machine.

The split changes the job. Lathe 2 ran 4 of the week's 14 changeovers and took 520 minutes, 130 minutes each.

The other five machines averaged 740 ÷ 10 = 74 minutes. The problem is Lathe 2's setup, not changeovers in general, so measure its changeovers before anyone redesigns them.

Cut the leading reason this way, in this order:

1. By machine, to see whether the reason is spread or concentrated.
2. By shift, to see whether one crew or one handover drives it.
3. By day of the week, to catch a pattern a single day hides.
4. By the operator's notes, to group causes inside the reason.

Stop cutting once a slice names a person who can act on it. The weekly downtime review takes it from there. For Lathe 2, that is the process engineer who owns its setup.

Compare two periods without fooling yourself#

Compare each reason as a share of scheduled time, not as raw minutes. A short week, a holiday or a machine that sat with no job all shrink the minutes without anything getting better.

The fix worked, but most of the raw drop came from the shorter week. Report the normalized number. It uses the same denominator as availability: the time the machine was meant to run.

Watch the ranks as well as the bars. A reason that falls from first to third may have shrunk, or another reason may have grown past it. Read both periods' totals before you call a win.

Get the Pareto without a spreadsheet#

A SenseAi sensor on each machine detects every stop in seconds, with no PLC connection, and operators put a reason on it in a tap. Automatic rules classify short downtimes, shift starts and ends, and breaks.

The Downtimes report draws the Pareto as Downtimes by Category, ranked by duration with a cumulative line. Two stacked charts split the same minutes by time interval and by machine, which covers the drill-down above. Filters cover shifts, categories and severity, and the CSV and PDF exports keep the filters you set.

Datwyler's injection molding plant reviews this report week over week and month over month, and cut shift-changeover downtime by 50% within six months. The full workflow is on downtime tracking.

Checklist before you act on the chart#

Run these checks each time you build a downtime Pareto:

• The window is four weeks or more for ranking, and the scheduled hours are written beside the chart.
• The bars are minutes, with the count and cost views kept as separate charts.
• Unclassified and Other sit outside the top three, or fixing them is the first action.
• Planned stops you can shorten are on the chart, and breaks and empty shifts are off.
• The vital few end where the line flattens, with one owner and a date named for each.
• The leading bar is split by machine and shift before anyone starts a fix.
• The next period is compared as a share of scheduled time, not as raw minutes.

To see where each reason sits in OEE, map it to the six big losses.