Machine Downtime: How to Track It, Cost It, and Actually Reduce It

Machine downtime is any period when equipment that is scheduled to produce is not producing. You manage it by logging every stop with a start time, a duration, and a reason code; costing it in dollars per minute; and attacking the biggest reason codes first. Plants that skip the logging step are guessing.

Most plants believe they know their downtime. Ask three people on the same line how much the line was down last week and you will usually get three different numbers, because the stops live on a clipboard, in a supervisor's memory, or nowhere at all. This guide covers the full loop: what counts as downtime, how to track it, how to put a dollar figure on it, and a working reason-code taxonomy you can copy today.

What counts as machine downtime?

Machine downtime is any time a machine is not running during a period when it was scheduled to run. That last clause matters. A line that is idle overnight because there is no third shift is not "down" — it was never scheduled. A line that stops for twenty minutes during a scheduled shift is down, whether the stop was a breakdown, a changeover, or an operator waiting on material.

Downtime splits into two families, and the split drives everything downstream:

• Planned downtime is scheduled in advance: preventive maintenance, changeovers, sanitation, trials, training. You chose it, so the goal is to shrink and standardize it, not eliminate it.
• Unplanned downtime is everything that surprises you: breakdowns, jams, material starvation, quality stops, no operator. Nobody chose it. The goal is to eliminate the causes, starting with the most expensive ones.

There is a third bucket plants routinely ignore: micro-stops — stops under a couple of minutes. A jam that an operator clears in ninety seconds never makes it onto a paper log, but thirty of them per shift can quietly cost more than one dramatic breakdown. If your tracking method cannot see micro-stops, your downtime total is a floor, not a fact.

Downtime is also the "A" in OEE. Availability = run time ÷ planned production time, and unplanned stops are usually the biggest single drag on it. If you are working on OEE, downtime tracking is where the signal is.

What is equipment downtime analysis?

Equipment downtime analysis is the practice of examining logged downtime events — their frequency, duration, reason codes, and context — to find which machines, causes, shifts, or products drive the most lost production time, so you can fix causes instead of symptoms. It turns a pile of stop records into a ranked to-do list.

In practice, downtime analysis answers four questions, in order:

• Where? Which machine or line loses the most scheduled time? Rank by total minutes lost, not by number of events.
• Why? Within the worst machine, which reason codes dominate? A Pareto chart of minutes by reason code almost always shows three or four codes carrying most of the loss.
• When and on what? Does the loss cluster on a shift, a product, a crew, a day of week, or right after changeovers? This is where context data (line, shift, SKU) earns its keep.
• Is it frequency or duration? Many short stops point to a process or material problem an operator can help fix. Few long stops point to an equipment or spares problem for maintenance. The fix is different, so the analysis has to separate them — mean time between failures (MTBF) for frequency, mean time to repair (MTTR) for duration.

The output of good analysis is not a dashboard. It is a short, ranked list of causes with an owner and a countermeasure next to each one, revisited weekly. Analysis that does not change next week's actions is reporting, not analysis.

How do you start tracking machine downtime?

You start tracking machine downtime by recording four things for every stop — which machine, when it started, how long it lasted, and why — using reason codes an operator can pick in under ten seconds. Everything else about a downtime program is built on those four fields.

There are three levels of capture, and most plants should not start at level three:

• Paper or spreadsheet logs. Better than nothing, but stops get rounded, micro-stops vanish, and the data arrives a day late. If this is where you are, the fastest upgrade is simply moving the same log to a tablet at the station, so the record is structured and timestamped the moment it happens.
• Operator-logged digital capture. The operator taps the reason on a tablet when the line stops. You get timely, coded events plus the one thing sensors can never give you: the human's read on why it happened.
• Automatic capture from the machine. A PLC signal or sensor detects the stop and its exact duration; the operator only supplies the reason code. This catches every micro-stop and removes rounding. It is the end state, not the prerequisite — a line can run operator-logged capture this month and add machine signals later.

Common tracking mistakes

Four failure patterns account for most dead downtime programs. Recording only maintenance-worthy events — if the log only captures breakdowns that generated a work order, you are blind to jams, starvation, and changeover overruns, which frequently outweigh breakdowns. Reconstructing at shift end — a stop logged four hours later gets rounded to the nearest quarter hour and assigned the reason that is easiest to remember, not the one that happened. Letting every department keep its own log — maintenance has one record, production another, quality a third, and the monthly meeting is spent arguing about whose number is right instead of what to fix. Punishing the data — the first time a reason code is used to blame a crew, honest coding ends and "Other" becomes the top category within a month.

Two rules make or break adoption. First, the reason-code list must be short and physical — codes an operator recognizes on sight, not an engineering taxonomy with ninety entries. Second, the data has to visibly get used. Operators stop logging honestly the week they conclude nobody reads it. Review the codes at the shift meeting, fix something the log surfaced, and say so.

Where does the data live? Anywhere structured beats paper: a shared digital form, a CMMS for the maintenance-driven events, or an operational platform that ties stops to line, shift, and product automatically. What matters is one system of record, not five partial ones.

A downtime reason-code taxonomy you can copy

A good taxonomy has two levels — category, then code — and fits on one screen. Aim for 15 to 25 codes total. Fewer and everything lands in "Other"; more and operators stop reading the list. Here is a starting taxonomy that fits most discrete and packaging operations. Rename freely; the structure is the point.

Three rules for keeping it healthy: give every code one unambiguous physical meaning; cap "Other" — if it exceeds roughly 10% of coded minutes, a real cause is hiding in it and deserves its own code; and resist code sprawl by reviewing the list quarterly, merging codes nobody uses.

The full taxonomy, with definitions for every code and guidance on tailoring it, is available as a standalone reference: download the downtime reason-code taxonomy.

How much does machine downtime cost?

Machine downtime costs whatever the line would have earned or absorbed while it was stopped, and the honest way to state it is dollars per minute. The formula:

Downtime cost per minute = lost contribution margin per minute + direct labor per minute + scrap and restart cost per minute (plus overtime or expediting when a stop forces them).

One judgment call first: is the line capacity-constrained? If everything you make is sold, every lost minute is lost sales, and lost margin belongs in the number. If the line has slack and can make the units up later, the cost of a stop is mostly labor, restart scrap, and the overtime used to catch up — smaller, but never zero.

Example scenario — hypothetical numbers, for illustration only. Take a sold-out packaging line:

• Runs 120 units per minute at a $0.30 contribution margin per unit → $36.00/min in lost margin.
• Crew of four at $25/hour fully loaded stands idle → $1.67/min.
• A typical stop on this line averages 12 minutes and produces about $150 of startup scrap and rework → $12.50/min averaged across the stop.

That is roughly $50 per minute. If the line loses 45 unplanned minutes per day — two mid-size stops and a scatter of micro-stops, a very ordinary day — that is about $2,250 per day, or around $560,000 per year on a 250-day calendar. From one line. The point of the arithmetic is not the specific figure; it is that a per-minute rate turns "the line was down a while" into a number a plant manager can rank against every other spend.

Two refinements once the basic number exists. First, compute a per-minute rate for each major line rather than one plant-wide average — the spread is usually large, and it should change where maintenance and engineering hours go. Second, attach the rate to your reason-code data: dollars per code is a sharper Pareto than minutes per code, because a 30-minute stop on the bottleneck line outranks a 90-minute stop on a line with slack. When downtime is stated in dollars, the conversation about fixing it moves from the maintenance office to the front office, which is where the budget lives.

Run your own lines through the math with our downtime cost calculator — it handles the capacity-constrained and non-constrained cases.

The downtime data model: event, reason, context, analysis

Tracking falls apart when stops are recorded as free text in one place, reasons in another, and production context nowhere. The fix is a simple data model: every downtime event carries its reason code and its context, so analysis is a query instead of a reconciliation project.

With this model, questions like "which SKU causes the most jams on Line 2?" or "is second shift's downtime a crew issue or a product-mix issue?" take seconds. Without it, they take a week of spreadsheet archaeology and still end in an argument.

How do you actually reduce machine downtime?

Tracking is table stakes; reduction is the payoff. This is the sequence that works, in order:

1. Get honest capture on one line. Pick your worst line and log every stop for two weeks with the taxonomy above — including micro-stops if you can. Do not launch plant-wide on day one.
2. Cost the loss. Convert minutes to dollars with the per-minute formula. A $560,000 number gets a different meeting than "the line was down a lot."
3. Pareto the reason codes. Rank codes by total minutes and by total dollars. Take the top two or three; ignore the rest for now.
4. Separate frequency problems from duration problems. Many short stops call for process, material, or operator-side fixes. Few long stops call for maintenance strategy, spares, and troubleshooting aids — see our guide to equipment reliability.
5. Run a root cause on the top code, not the top incident. Use 5 Whys or a fishbone on the pattern ("EQ-MECH on the capper, 40 events, all under 8 minutes"), assign an owner and a countermeasure with a date.
6. Attack planned downtime separately. Standardize changeovers, tighten PM execution, and stop letting planned windows overrun. Planned downtime responds to discipline faster than unplanned downtime responds to engineering.
7. Close the loop weekly and re-rank. Review the Pareto every week with operators in the room. When the top code drops, the next one is already ranked. This loop, run indefinitely, is the whole program.

Where maintenance strategy fits

Downtime tracking tells you where the pain is; maintenance strategy decides how you prevent it. The two are usually out of balance: the U.S. Department of Energy's Federal Energy Management Program O&M Best Practices Guide pegs typical facilities at 40–60% of maintenance effort spent reactively — fixing things after they break — while best-in-class operations hold reactive work under 10%. The same guide estimates a functioning preventive maintenance program saves 12–18% over a reactive one, and predictive techniques save a further 8–12% over preventive alone.

Translating that: every hour of reactive firefighting your downtime log reveals is an argument for shifting effort upstream — into scheduled PM, into operator-led care of equipment (see total productive maintenance), and into work-order discipline in a CMMS. Your reason-code data is exactly what tells you which machines deserve that investment first.

What good looks like

A plant that has this working shares a few habits: every stop is captured the moment it happens, at the station, not reconstructed at shift end; supervisors see stops in real time instead of in tomorrow's report; the Pareto is reviewed weekly with the floor; and the downtime record ties into quality and production data, because the same context explains all three.

This is the problem Harmony's downtime and quality intelligence is built for: operators capture stops and reasons on tablets at the station, machine and PLC signals feed the same record, and patterns across defects and downtime surface automatically — with availability computed from source data rather than estimated. It layers onto the ERP, MES, and machines a plant already runs. No rip-and-replace. Chattanooga Labeling Systems went from paper production logs, where downtime events were reviewed the next morning, to seeing stops as they happen and intervening during the same shift — read the case study, or see how the platform fits together.

Start smaller than that if you need to. One line, twenty reason codes, two honest weeks of data. The Pareto will tell you what to do next.