Most shops that track downtime end up with a spreadsheet full of stop codes. But nobody knows what to fix first. The data exists, but it just sits there. A Pareto chart fixes that. It turns a pile of downtime tracking data into a short, ranked list of the two or three causes worth an engineering hour this week.
This guide walks through how to build a downtime root cause analysis using a Pareto chart, the right way. You'll also see the mistakes that make most Pareto charts useless, and how to turn the result into a fix that actually gets assigned to someone.
Tired of downtime causes being logged as vague notes nobody can act on? See how automatic cause capture fixes that at the source.
Explore Machine MonitoringA Pareto chart ranks downtime causes from most frequent to least. A line on top shows the running total as a percentage. The idea behind it is simple: a small number of causes usually explain most of the downtime. In a typical CNC shop, two or three stop reasons often explain 70 to 80 percent of total lost time. Everything else is a long tail of one-off causes.
The chart itself isn't the point. The point is the decision it forces. Instead of spreading maintenance time evenly across every cause in the log, you put it where it actually moves the number: the few causes at the top of the list.
A Pareto chart is only as good as the cause codes behind it. Two problems come up constantly:
Where the codes come from matters too. Operator-entered causes, filled in from memory at the end of a shift, tend to undercount short, frequent stops. People remember the one dramatic breakdown, not the ten small ones. Machine-signal-based capture, tied to the actual stop as it happens, gives you a cleaner base to work from, especially for those short, repetitive stops that are easy to forget by report time.
Start with clean cause codes over a representative period. Two to four weeks is usually enough to smooth out day-to-day noise, without waiting too long to act. From there, the construction is simple:
Minutes, event count, and cost each tell a different story. A cause with many short stops might dominate an event-count chart, while barely showing up on a minutes-based one. A cause tied to an expensive part or a bottleneck machine might dominate a cost-based chart, while looking minor on the other two. Pick the metric that matches the decision you're trying to make. If the rankings disagree across metrics, that disagreement is itself useful: it tells you which fix has the biggest business impact.
Look at where the running percentage line crosses roughly 80 percent. The causes to the left of that point are your vital few. In practice, this cutoff is rarely clean or obvious. Treat it as a starting point for judgment, not a hard rule. A cause sitting just past the 80 percent mark that's cheap and fast to fix is often worth including anyway. A cause just inside the mark that would require a major process change might reasonably get pushed to next month.
Watch for a flat Pareto chart, where no cause stands out and every bar is roughly the same height. That usually means one of two things. Either your cause codes are too coarse, and several distinct problems are hiding under one umbrella code. Or your data window mixes different operating conditions, like a week of operator training blended with a week of stable production. Re-segment the data before you conclude there's no vital few to find.
Want a live breakdown of downtime by cause instead of reconstructing it after the fact? See every stop reason as it happens across the floor.
See Production MonitoringThis is the step most shops skip. It's also the one that actually matters. A Pareto chart that ends up as a slide in a meeting has produced nothing. For each of the vital few causes, turn the chart into three things:
A good rule of thumb: cap the list at the top two or three causes per cycle. Ten assigned action items spreads your effort thin, which is exactly what a Pareto chart is supposed to prevent.
Monthly works for most shops. That's frequent enough to catch a shifting cause structure, but infrequent enough that each cycle has real data to work with, and enough time has passed to judge whether last cycle's fixes worked. Shops running high-mix, short-run work may need a shorter window, since the job mix itself changes fast.
The cadence matters less than the habit. Treat this as a recurring review, not a one-off project. The same discipline used to prioritize KPIs more broadly works here too: see our weighted scoring approach to prioritizing production KPIs for the same idea applied across a shop's full metric set, not just downtime.
A downtime Pareto chart is only worth building if it changes what gets fixed first. Used well, it turns a shift's worth of logged stops into a short list an engineer can act on this week, not a report that gets filed away. The habit matters more than any single chart: run it, assign the fix, check that the bar actually shrank, and repeat.
Curious what fixing your #1 downtime cause is actually worth? Estimate the impact on your bottom line.
Calculate Your ROIWhat is a Pareto chart used for in manufacturing?
It ranks causes of a problem, downtime, scrap, or any other loss, from most to least significant, with a running percentage showing how much of the total each cause accounts for. In manufacturing, it's most often used for downtime root cause analysis. It shows you which stop reasons or defect types are worth fixing first, since a small number of causes usually account for most of the loss.
How many downtime causes should go into a Pareto chart?
There's no fixed number. It depends on how many distinct causes show up in your data. What matters more is the resolution of your cause codes. Codes that are too broad hide the real drivers inside a catch-all bucket. Codes split too finely can make one real driver look small when it's really several near-duplicate entries that should be combined.
How is a Pareto chart different from a fishbone diagram?
A Pareto chart ranks causes you already have data on, to show which ones matter most. A fishbone (Ishikawa) diagram comes earlier in the process. It's a brainstorming tool used to generate a broad list of possible causes, across categories like machine, method, material, and manpower, before you necessarily have data on any of them. The two work well together. The fishbone diagram helps you generate the list of candidate causes. The Pareto chart tells you which ones on that list are actually worth acting on.
How often should a downtime Pareto analysis be updated?
Monthly works for most shops. That's frequent enough to catch a shifting cause structure and judge whether previous fixes worked, while still leaving enough data in each window for the ranking to mean something. Shops with high-mix, short-run work, where the job mix itself changes quickly, may need a shorter cycle to keep the tracking relevant.