How to reduce machine downtime, one cause at a time

A practical plan to cut unplanned downtime has four steps. Record every stop from the machine, put a reason on each one, rank the reasons by the hours they cost, then fix the leading reason with the lever that matches its pattern: fewer stops, or shorter ones. Check the result against the same window a month later, then move to the next reason.

This guide is for plant managers and maintenance leads. It takes one four-week stop log from an eight-machine CNC cell through the whole plan, from 9.0% unplanned downtime to 7.0%.

What counts as unplanned downtime?#

Downtime is all stopped time, planned or not. Planned production time is the time a machine is scheduled to run, after breaks and other time nobody meant to run it come out.

Planned stops are breaks, scheduled maintenance and planned changeovers. They stay out of the rate below, so a busy month of preventive maintenance doesn't look like a reliability problem.

Changeovers still take capacity. Shortening them is its own project, with its own start and stop rules: see how to measure changeover time.

For context, NIST surveyed US discrete manufacturers on their 2016 operations.^[2] Downtime averaged 7.8% of planned production time across the sample.^[1] Respondents attributed 31.7% of that downtime to reactive maintenance, meaning unplanned maintenance and repair, which leaves about two thirds to other causes.^[1]

That split shapes the plan. A program that only targets repairs leaves most of the stopped time alone. Material, staffing and programs belong on the same list as breakdowns.

Measure a baseline before you change anything#

A fix you can't compare with a before number is a guess. Record four weeks of stops on every machine in the area first, and change nothing while you do.

Take the stops from the machine signal, not from memory. A paper log catches the 40-minute breakdown and misses the 90-second jams, because nobody writes those down. The full method is in how to track machine downtime.

Each stop needs four fields: the machine, the start, the end and a reason. Keep the reason list short enough that operators pick the right one in seconds. A starter list is in which downtime reason codes to log.

Rank the reasons by hours#

Sum the hours under each reason and sort from largest to smallest. Rank by hours, not by number of stops, because the question is which reason takes the most capacity.

By count, short stops lead with 720 and breakdowns come last with 8. By hours, waiting for material and breakdowns lead, and together they carry 88 of the 216 hours. Those two get the first fixes.

Pick two reasons, not five. Each fix needs an owner, a target and a month of follow-up, and a team that runs five at once can't tell which one worked.

To build the chart and its cumulative line, see how to build a downtime Pareto. To weigh reasons by dollars instead, see how to price an hour of downtime.

Split each reason into how often and how long#

Every reason's hours are the product of two numbers you can attack separately.

The two leading reasons cost about the same, in opposite ways. Breakdowns are 8 stops of 300 minutes each. Waiting for material is 64 stops of 45 minutes each.

A faster repair crew does nothing for the material waits, and better material staging does nothing for the breakdowns.

Read the chart by position. A reason near the top is a duration problem: each stop lasts too long. A reason far to the right is a frequency problem: the machine stops too often, and each stop is too short for a faster response to matter.

Match the fix to the pattern#

Once you know whether a reason is frequent, long or both, the lever follows.

Cut how often it stops#

A frequency fix removes the cause, so the stop never happens. Ask what the machine was waiting for, and change the step upstream that made it wait.

In the example cell, the material waits come from jobs released before their bar stock reaches the machine. Suppose the cell starts staging material at the machine one job ahead.

Stops fall from 64 to 24, and each still lasts 45 minutes: 24 × 45 = 1,080 minutes, or 18 hours. The reason drops from 48 hours to 18, saving 30.

Short stops need the same approach at a smaller scale: the jam, misfeed or sensor trip behind them. The cutoff and the OEE effect are in micro-stops. When the same failure mode keeps returning, prevention belongs here too: see how to choose a maintenance strategy for when a PM on run hours or on machine condition beats the calendar.

Cut how long each stop lasts#

A duration fix accepts that the stop will happen and shortens it. Split one long stop into the time spent on each step, then cut the waiting steps first, because waiting adds minutes without adding repair.

In the example, 165 of the 300 minutes are waits: 45 for a technician to arrive and 120 for parts. Two changes take most of that out:

• An alert at 10 minutes to the technician on shift, so nobody has to walk to the maintenance shop. The technician arrives 15 minutes after the stop instead of 45.
• The two parts that fail most held at the cell, so the parts wait falls from 120 minutes to 15.

Each breakdown now lasts 165 minutes. Over eight breakdowns that is 1,320 minutes, or 22 hours, down from 40.

Set the alert above the machine's normal changeover and tool-change length. An alert that fires on every planned stop gets ignored within a week, and then it doesn't shorten the breakdowns either.

You don't need a predictive maintenance program to start. The first two fixes in most plants come from a stop log with reasons, a weekly look at the top of the ranking and an owner for each fix.

Set a target and check that it held#

Set the target on the reason, not on the plant total. "Waiting for material under 20 hours in four weeks" can be checked. "Less downtime" can't.

Compare the same four-week window, on the same machines, as a share of planned production time. A short week with a holiday has fewer stops and proves nothing.

The cell gets 48 machine hours back every four weeks, 12 hours a week. If a reason doesn't move, check whether the fix ran on every shift before you drop it.

Small, repeating losses only show up in the weekly view. At Datwyler's injection molding plant, week-over-week reports showed that Tuesday shift transitions added 8 to 10 minutes of downtime every week. Acting on patterns like that, the plant cut shift-changeover downtime by 50% and material-changeover downtime by 30% within six months (Datwyler story).

To run that review in 30 minutes with a one-page report, see how to run a weekly downtime review.

Run the plan with IoTFlows#

A SenseAi sensor on each machine detects every stop in seconds, with no PLC connection. Operators add the reason in a tap, and four automatic rules classify routine stops such as short downtimes and shift starts and ends.

The Downtimes report ranks reasons by the hours they cost and trends them by week and by machine, which is your before-and-after check. A Machine Down alert reaches the right person at a warning time and a critical time. A classified stop opens a work order in Maintain from the same dialog, with the machine and reason filled in.

Within the first month, Sorinex achieved 60% faster issue identification and resolution, with real-time downtime categorization (Sorinex story).

Your first 90 days#

1. Weeks 1–4: record the baseline

   Capture every stop on every machine in the area, with a reason on each. Change nothing yet, and write down the planned production time.

2. End of week 4: rank and pick two

   Rank reasons by hours and pick the top two. Check that Unclassified is smaller than the third reason.

3. Split each reason

   Write down the stop count and the minutes per stop for each of the two. Decide whether each is a frequency fix, a duration fix or both.

4. Weeks 5–8: run one fix per reason

   Give each fix an owner and a target in hours for the next four weeks. Track the number the lever moves: stops for frequency, minutes for duration.

5. Weeks 9–12: compare and decide

   Compare the reason with its baseline on the same machines and the same window length. Keep the fixes that held, make them standard work, and pick the next reason from the new ranking.