CNC machine downtime: causes, cost, and how to track it

Planned downtime is non-production you chose in advance: preventive maintenance, breaks, changeovers you scheduled, windows with no demand. Unplanned downtime is everything that stops a machine you expected to be cutting.

The line between them is not physics — it is policy. Is a changeover that was scheduled but ran 30 minutes over “planned”? Is a tea break that stretched? Every plant answers differently, and both answers are defensible. What is not defensible is answering differently on different shifts: the moment the boundary drifts, your availability trend measures your classification habits, not your machines.

Two things are reliably true across floors. First, every plant’s ranking is different— which is why your own measured Pareto beats any generic list, including this one. Second, the categories people expect to dominate (breakdowns) usually don’t: changeover, tooling, and starvation typically outweigh genuine machine failures on well-maintained CNC floors.

A micro-stop is any stop short enough that nobody would ever log it — two minutes waiting for the crane, ninety seconds at a door open, three minutes between the last part of one batch and the paperwork for the next. Individually they are nothing. Arithmetically they are brutal: twelve 4-minute stops is 48 minutes — an entire hour’s production per shift, invisible.

Micro-stops are why plants that track downtime manually still “lose” hours they cannot explain: the logbook shows two stops totalling 40 minutes, the output is 90 minutes short, and the difference gets blamed on the operator or the standard. Neither is guilty — the missing time went out in slices too thin to see.

This is the single strongest argument for automatic stop detection from the controller: machines notice every stop, however short, with exact timestamps. People shouldn’t have to.

The formula is simple: lost machine-hours × fully loaded machine-hour rate. The two mistakes are both underestimates: counting only the stops you noticed (see micro-stops above) and using a rate that only covers the operator’s wage. The honest rate includes power, overhead absorption, and the contribution margin of the parts that were never made.

A worked example — illustrative numbers, substitute your own: a 15-machine floor averaging 45 minutes of unclassified downtime per machine per day, at a loaded rate of ₹1,200/machine-hour, over 25 working days:

• 15 machines × 0.75 hr × 25 days = 281 machine-hours/month
• 281 × ₹1,200 = ≈ ₹3.4 lakh/month
• × 12 = ≈ ₹40 lakh/year — from stops mostly too small to log

Run your own numbers in the downtime cost calculator. The point of the exercise isn’t precision — it’s that the annual figure is always larger than anyone’s intuition, because intuition experiences downtime five minutes at a time.

• Memory, not measurement. Logs are filled at shift end, reconstructing eight hours from memory. The 35-minute breakdown makes it in; the twelve small stops never do.
• Incentives point the wrong way.When downtime reasons carry blame, categories drift toward the blameless: “machine problem” absorbs everything. The data becomes politically correct and operationally useless.
• Granularity costs the writer.Precise logging competes with restarting the machine. Any system where good data costs the operator time will get bad data — reliably, and not through anyone’s fault.
• Compilation eats the benefit. A supervisor spending Saturday turning logbooks into a monthly Excel is spending the exact hours the analysis was supposed to save.

The fix isn’t better forms or stricter discipline. It’s changing what humans are asked to do: machines report that and when they stopped; people contribute only the why — in seconds, at the machine, without blame attached.

• Detect stops automatically, from the controller. Every stop, exact start and end, with the controller alarm attached when one exists. No threshold below which stops vanish.
• Classify with two taps, at the machine. Category, then reason, from a tree that uses your plant’s vocabulary. More taps than two and classification discipline decays within weeks.
• Make unclassified downtime loud.A visible “downtime to justify” counter turns unnamed stops into an open item someone owns, instead of a silent data hole. This single mechanism is what builds the classification habit.
• Keep planned and unplanned separated by policy, automatically. The written policy from section one, encoded once, applied by the system on every shift.
• Report as a Pareto, per machine, in minutes. Percentages hide size; minutes convert directly to ₹ and to arguments won.

This is precisely the loop ThingConnect’s downtime tracking implements — automatic detection from the controller, two-tap classification on the shop-floor tablet, and a live loss Pareto.

Data alone reduces nothing — plants with dashboards and no ritual keep their downtime and gain a screen. The ritual that works is short and boring:

• Ten minutes, every morning, at the board. Yesterday’s Pareto, per line. Top bar gets discussed; the rest doesn’t.
• One action per top bar, with a name on it. Not a project — an action. “Rajesh checks why TM2’s changeovers ran double this week.”
• Unclassified minutes get named first.The “to justify” count goes to zero before anything else is debated — otherwise the Pareto lies.
• The trend chart hangs where operators see it. Downtime falling week over week is the only motivation scheme that doesn’t backfire.

Whatever your Pareto shows, the top bar is usually one of these three — and each has a known playbook:

• Changeover/setup: separate internal from external setup (classic SMED) — pre-stage tools, fixtures, and programs while the machine still cuts the previous job. Measured changeover time typically drops 30–50% from discipline alone, before any hardware is bought. First-off approval waits are their own sub-bar: measure them separately and they usually embarrass someone into fixing the process.
• Tooling: track tool-related stops by reason (change, breakage, adjustment). Breakage clusters point at specific parts, materials, or parameters; frequent adjustment points at offsets and process stability. Tool-life management pays for itself in stops that never happen.
• Starvation:the machining section rarely controls its cause — but measured “waiting for material” hours are the evidence that gets upstream scheduling, the crane roster, or the foundry to move. Data wins the argument that opinion has been losing for years; see the foundry machine-shop page for the casting-fed version of this problem.