Machine downtime tracking: recording downtime reasons and finding the real losses

What is machine downtime tracking?

Every downtime record holds four things: which machine, when it stopped, when it started again and why it stopped. The first three give the duration and the last one gives the reason. Duration answers "how much did we lose?" and the reason answers "what should we fix?". If either is missing, the record is of little use. A duration with no reason is just a number, and a reason with no duration is just a complaint.

Downtime tracking looks like a maintenance topic, but it is really about capacity. Without knowing how much of its planned time a machine actually runs, you cannot promise due dates with confidence or answer "do we need another machine?" honestly.

Why tracking downtime matters

• Unrecorded downtime is hidden capacity you never use. In most shops the loss is bigger than people think, because each short stop looks too small to matter.
• Due dates suffer too. If a job shows as "on the machine" but is really waiting for material, the delay is only noticed on the due date.
• Breakdown, setup or material? Without reasons, improvement effort goes to the problem people talk about most, not to the biggest one.
• The availability factor of OEE comes straight from downtime records. No downtime data, no OEE. The formula is in how to calculate OEE.
• It helps with quotes and planning as well. Once setup times and recurring waits are known, time estimates get closer to reality.

Here is a quick calculation. In a shop with 8 machines, if each one loses an average of 40 unrecorded minutes per shift, that is 320 minutes a day, more than 5 hours. Over 22 working days it comes to about 117 hours a month. That is more than one machine running a single shift for the whole month.

Planned, unplanned, setup and maintenance downtime

Not every stop is a loss. A machine stopped for a break says nothing about a problem, but a machine stopped by a breakdown does. So group the reasons from the start and decide which groups count as losses:

Some shops feel it is unfair to count setup as a loss, since setup is part of the job. But setup time can be reduced, and leaving it out hides one of the biggest improvement opportunities. In job shops that change parts often, setup is frequently the largest downtime reason of all.

How to build a good list of downtime reasons

1. Keep it short. 8 to 15 reasons is enough. If operators cannot read the list at a glance, they pick the first one they see and the data stops meaning anything.
2. Leave out "Other". If "Other" exists, most stops end up there. If a common reason is missing, add it to the list instead.
3. Use the words of the shop floor. An operator says "tool broke". Nobody on the floor says "unplanned stop caused by cutting tool".
4. Give every reason a group. Planned, setup, unplanned or maintenance? That choice decides how the stop counts in OEE and whether it raises an alert.
5. Name the cause, not the person. "Maintenance didn't come" is a consequence, and the reason is "machine breakdown". Reasons that point at people make operators stop recording.
6. Review the list every quarter. Remove reasons nobody uses, and split a broad reason that is picked very often into two.

Paper, Excel or software

The real problem with paper and Excel is not the medium but the timing. An operator who writes up at 5 pm a stop that began at 2:10 pm guesses the duration and forgets the short ones. In software the operator only picks the reason, because the time is already recorded. Moving off paper is covered in what a paperless MES really removes, and off spreadsheets in MES vs Excel.

What to look at in downtime analysis

Total time by reason (Pareto)

The first and most useful analysis is to add up downtime by reason and sort it from largest to smallest. A few reasons usually make up most of the loss. Here is one week on a group of CNC machines:

Here the top two reasons are about two thirds of the loss. Breakdowns get the most attention, yet they come fourth. Improvement should start with setup time and with getting material to the machine on time. For setup, that means preparing the next job while the machine is still running and presetting tools.

Frequency or duration?

The same total can hide two different problems. One is a 3-hour breakdown once a week, the other is ten 4-minute jams a day. The first is a maintenance issue and the second is a process or setup issue. Look at both the total time and the number of stops for each reason.

MTTR and MTBF

• MTTR = Total breakdown time ÷ Number of breakdowns. MTTR is the mean time to repair. If the 180 minutes of breakdowns in the example came from 4 separate breakdowns, MTTR is 45 minutes. A falling MTTR means breakdowns are being fixed faster.
• MTBF = Total run time ÷ Number of breakdowns. MTBF is the mean time between failures. A rising MTBF means the machine fails less often. It is how you see whether preventive maintenance is working.

Share of stops with no reason

Track separately how much of the downtime has no reason. If that share is high, the analysis cannot be trusted and the recording habit needs fixing first. A high share in the first weeks is normal. Aim to bring it under 10% within a few weeks.

Common mistakes

1. Forcing a reason and rushing the operator. If a reason is mandatory to pause and operators tap the first row to get on with it, the data is wrong. A wrong reason is worse than a missing one, because a missing reason can at least be asked about later.
2. Counting breaks and "no work" as losses. Putting planned stops in the same bucket as breakdowns makes the loss look bigger than it is and hides the real problem.
3. Recording only long stops. A rule like "nothing under 15 minutes" wipes out the most common losses, which are short jams and waits.
4. Using the data to judge people. If downtime records are used against operators, stops stop being recorded. Downtime tracking is for fixing the process.
5. Recording and never looking. Fifteen minutes a week on the top three reasons does more than a long report once a month.

Machine downtime tracking in ModernMES

ModernMES records downtime from something operators already do, which is pausing the job. When an operator taps Pause on the terminal or their own phone, a "Why did it stop?" window opens and they tap one of the large reason buttons. Every pause opens a downtime record for that machine, and resuming or finishing the job closes it. Start, end and duration are stored with the machine, so nobody has to write down a time.

• So downtime can be recorded on day one, 12 reasons come built in, sorted into four groups. Planned covers break/lunch, shift change and no work. Setup covers machine setup/mold change and first-part approval. Unplanned covers machine breakdown, tool breakage/change, waiting for material, no operator, quality problem and power/infrastructure outage. Maintenance covers planned maintenance. Each reason is marked as counting toward OEE or not, so a break does not count and a breakdown does. You can rename them and add your own under Settings → Downtime reasons and defect types.
• Operators can also choose "Pause without a reason". The stop is still recorded with its duration and only the reason is left empty. The terminal does not force a choice, because an operator who is forced either picks the wrong reason or leaves the machine marked as running.
• Stops without a reason wait in their own list. A manager who taps the "Stop with no reason" alert opens that list and gives each stop its reason after the fact.
• Settings → Alerts has two rules for this. "Machine stopped" fires once a machine has been stopped for the time you set, 5 minutes by default. Planned stops do not count, and if a reason was chosen the alert says which. "Stop with no reason" fires when a stop without a reason passes the time you set, 10 minutes by default. You choose the time and which roles receive each alert. Alerts arrive in the bell in the panel.
• The live shop floor view shows which machines are running, which are waiting and who is on each one, refreshing every 15 seconds. It can open full screen on a TV on the shop floor.

Machines can report their own state

To catch the stops operators do not record, a machine's running/stopped state can also come in automatically. You set this up under Settings → Machine signals. On machines with a PLC, a gateway or Node-RED reads the running bit and sends it over MQTT. If the state already lives in another piece of software, it can be sent over HTTP. Older machines without a PLC can use a sensor box with a current clamp on the motor cable or a vibration sensor. Machines with an OPC UA server also connect through a gateway or Node-RED over MQTT. ModernMES does not connect to OPC UA directly.

With a machine in "Signal + operator" or "Automatic" mode, a running machine that stops for longer than the stop grace time gets a downtime opened automatically, which then waits for its reason. Shorter pauses are not counted as downtime. A machine has only one open downtime at a time. If the operator pauses the job during it and picks a reason, the reason is written to the downtime the signal opened, so nothing is counted twice. The default mode is Manual, in which incoming signals are only recorded.

The signal only carries running or stopped. Good and scrap quantities always come from the operator, so connecting a sensor does not replace operator input. It catches the stops that would otherwise be missed.

How the jobs themselves are tracked is in work order tracking. Have a look at the live shop floor demo, or start a 14-day free trial without a credit card. Plans are in the pricing section.

Frequently asked questions