How to build a downtime Pareto analysis

You have a month of downtime data and a spreadsheet full of stops. Now what? Staring at 130 logged events tells you nothing. A Pareto analysis turns that list into a single ranked picture that answers the only question that matters at the Monday production meeting: where does the time actually go?

This is a step-by-step guide to building a downtime Pareto from raw logged events, with a full worked example from a stamping line. If you have not yet built a clean reason code list, read a practical machine downtime reason code list first — a Pareto is only as trustworthy as the codes underneath it.

What a Pareto analysis actually tells you

A Pareto chart is a bar chart of your reason codes sorted from most to least, with a line running across the top showing the running cumulative percentage. The idea comes from the observation that a small number of causes usually account for most of the effect — the "vital few" versus the "trivial many." On a shop floor that means two or three reason codes typically drive the bulk of your lost minutes, and the other ten barely move the needle.

The value is focus. You cannot fix everything at once, and a Pareto tells you exactly which one or two problems to attack first to get the biggest return. It also protects you from the loudest-voice trap — the failure everyone complains about is often not the one costing you the most hours.

The data you need first

To build a Pareto you need three columns per reason code, aggregated over a fixed period:

That is it. If your log captures actual start and stop times, the minutes column is exact. If operators estimate durations, the Pareto still works, but treat the smallest bars with suspicion — estimation error clusters there.

Pick a period long enough to be representative but short enough to be current. Four to six weeks on a single machine is the sweet spot. Any less and one bad day distorts the ranking; any more and you are averaging over changes you already made.

The reason code (the category, not the free-text note).
The event count — how many times that code was logged.
The total downtime minutes for that code.

A worked example: 6 weeks on a stamping line

Here is six weeks of data from a 600-ton progressive-die press running two shifts, five days a week. Scheduled run time was 480 hours. Operators logged every stop over five minutes against a twelve-code list, closing each event when the press restarted.

The first step is to aggregate the raw events by code and sort descending by total minutes. Then add a percentage-of-total column and a running cumulative column. That cumulative column is what makes it a Pareto rather than a plain bar chart.

That is 66.7 hours of downtime against 480 scheduled hours — an availability of 86.1%. But the headline number is not the point of a Pareto. The ranking is.

Reading the 80/20 line

Run your finger down the cumulative column until it crosses 80%. Everything above that line is your vital few.

Here the line lands between Mechanical failure (84.5%) and Coil change (74.3%). So the top four codes — die change, tooling failure, coil change, and mechanical failure — account for 84.5% of all downtime. The other four codes combined are under 16%. If you fixed only the bottom four completely, you would recover barely a tenth of your lost time.

Notice the split is not a clean 20/80. Four of eight codes is 50% of the list, not 20%, driving 85% of the minutes. Real shop data rarely obeys the ratio exactly, and chasing a textbook 20/80 will mislead you. The rule is directional: a minority of causes drives a majority of the loss. The precise cutoff is whatever your cumulative line says. Here the honest read is even tighter — the top two codes alone are 61% of downtime. Start there.

Minutes versus frequency: run two Paretos

The Pareto above ranks by minutes. Build a second one ranked by event count and the priorities shift:

The minutes-per-event column is where the two views diverge, and it is the most diagnostic number in the whole analysis:

A minutes Pareto tells you where the hours went. A frequency Pareto tells you what goes wrong most often. You need both, because the same code can be a giant on one chart and invisible on the other.

Die change is your biggest bucket by both measures, but each event is only 32 minutes. This is not a breakdown — it is a changeover problem. Forty-eight setups is a SMED opportunity, and shaving ten minutes off each returns eight hours over the six weeks. That single change beats eliminating every mechanical failure.
Mechanical failure is rare but brutal. Five events, but 82 minutes each — the worst per-occurrence code on the line. It is only 10% of total minutes, so a minutes-only Pareto tempts you to ignore it. Do not. Five long unplanned stops is a reliability signal, and it belongs in a maintenance root-cause conversation.
Coil change is high-frequency, low-duration. Thirty stops of 18 minutes. Frequent short stops erode operator rhythm and often mask a staging or material-flow problem upstream of the press.

From Pareto to action

A Pareto is a decision tool, not a wall poster. Once it is built:

Pick the single top bar and assign an owner. Here that is die change / setup. Not "reduce downtime" — a named person running a SMED study on the top two dies.
Set a target tied to the chart. "Cut average changeover from 32 to 22 minutes by the next review." The Pareto is your baseline; you will rebuild it in six weeks and measure against it.
Watch the per-event outlier separately. Mechanical failure gets its own root-cause track even though it is not the tallest bar, because per-event severity is a different problem than total volume.
Ignore the tail on purpose. Quality hold and Other are under 6% combined. Leave them. Spending a meeting on the smallest bars is the most common way a downtime program stalls.

Common mistakes that break a Pareto

Charting free text instead of codes. If mech, mechanical, and bearing are three separate bars, your Pareto is fiction. Aggregate on a fixed code list first.
Ranking only by minutes. You will miss the rare-but-catastrophic failures that a frequency or per-event view exposes.
Mixing planned and unplanned in one bar. Die change is planned and usually dominates. If you do not label it, you will "discover" that your biggest downtime problem is a scheduled activity and waste a maintenance investigation on it. Keep the planned/unplanned split visible.
Rebuilding it once and never again. A Pareto is a snapshot. Its whole purpose is to be redrawn after you act, so you can see the top bar shrink. One chart tells you where the problems are; a series of charts tells you whether you fixed them.
Comparing Paretos across dissimilar machines. A press and a CNC cell have different natural failure profiles. Compare each machine's Pareto to its own history, not to the machine next to it.

Where HelpFab fits

Building a Pareto by hand in a spreadsheet works, but you rebuild the pivot table every time the date range changes. In HelpFab's Issues and downtime tracking, operators log each stop against a machine from a phone or tablet using your own configurable issue types, and the Issue Reports page has a dedicated Downtime Pareto view that sorts your codes by lost minutes over any date range you pick, alongside a downtime-over-time trend for watching whether the top bar is shrinking. Because the codes come from a fixed pick-list, there is nothing to clean before the chart is right, and reminders turn the top code into an assigned follow-up instead of just another bar.

The chart is the easy part, though. The hard part is a clean code list and honest durations underneath it — get those right, run the press for six weeks, and the Pareto will point at exactly what to fix first. If you are still deciding what to log and who logs it, start with how to track machine downtime.

Latest articles

Maintenance log vs downtime log — Maintenance log vs downtime log - what each one captures, why a plant needs both, and how a single breakdown links them to give you MTTR and MTBF.
Choosing a downtime tracking app for a small manufacturer — What a small shop should look for in a downtime tracking app: phone logging, configurable reason codes, and reports you can read without an ERP.
How to reduce unplanned downtime in manufacturing — A track-first playbook to reduce unplanned downtime - log every stop, Pareto the causes, then attack the vital few with PM and root-cause fixes.
How to calculate the cost of unplanned downtime — A cost-per-hour formula for unplanned downtime, with a worked molding-cell example covering labor, scrap, lost margin, and overhead.
A free downtime tracking Excel template (and how to actually use it) — A free Excel downtime log template — the columns, a reason-code list, and the pivot that turns raw stops into a Pareto, plus when to move off it.
OEE availability: how to calculate it from your downtime data — Calculate OEE availability from your downtime log, with a worked CNC example — plus the reclassification tricks that quietly inflate the number.
A practical machine downtime reason code list — A starter taxonomy of machine downtime reason codes — planned vs unplanned, with real fault-code examples and rules that keep operators logging honestly.
Downtime tracking spreadsheet vs software — When an Excel downtime tracker is enough and when it quietly breaks — a shift-by-shift comparison for small manufacturers, with a real cost example.
How to track machine downtime — Move from a paper downtime log to structured tracking: reason codes, who logs what, and the three reports that actually change decisions.