---
title: "How to track machine downtime and its causes"
description: "Let a machine signal record every stop and ask operators only for the reason. A worked shift, rules that name routine stops, and a first-week checklist."
category: "Downtime and utilization"
author: "Applications Engineering Team"
published: "2024-10-15"
updated: "2026-10-20"
source_url: "https://www.iotflows.com/blog/how-to-track-machine-downtime/"
---
> Question: How do I capture every stop and its reason without slowing production?

## Key takeaways

- A machine signal should record when each stop starts and ends, so operators only supply the reason.
- Paper logs miss stops of 1 to 3 minutes and round the long ones, so they understate downtime.
- Rules can name short stops, shift edges and breaks, leaving operators only the stops that need judgment.
- Give operators 8 to 12 reason codes, each named for something a person can fix and marked planned or unplanned.
- Check the unclassified share daily and rank reasons by minutes weekly, with an owner for each of the top three.

You capture every stop and its reason without slowing production by splitting the work. A machine signal records when each stop starts and ends, rules name the routine stops, and operators add a reason only to the stops a rule can't explain, in one tap at the machine. Nobody writes times down, so the record catches the two-minute stops a paper log misses.

This guide is for plant managers and maintenance leads setting up downtime tracking on a cell or a whole floor. It works one shift by hand, shows which stops a rule can name, and ends with a checklist for the first week.

## What a downtime record holds

> **Definition.** **Machine downtime** is the time a machine is stopped during scheduled production, from the moment it stops until it runs again. A stop counts in full whether or not anyone has recorded why it happened.

The second half of that definition is the one plants get wrong. A stop with no reason is still downtime, as the [downtime glossary entry](/docs/get-started/glossary/#downtime) puts it. A reason changes what you can say about stopped time, not how much of it there is.

Each stop becomes one record with a handful of fields. The trick is to ask each field from whoever already knows it.

Figure: Three sources feed one stop record. The machine signal supplies start 10:30:12, end 10:52:40 and 22 min 28 s; rules name routine stops; the operator adds the reason Breakdown and a note. The record feeds a weekly Pareto.

*One stop on a Haas VF-2: the machine supplies the times, and a person supplies only the reason. Sample data.*

The machine knows when it stopped and restarted, to the second. A rule knows that a 90-second pause is a short stop, or that a stop inside the lunch window is lunch. Only a person knows that the coolant pump tripped.

## Why paper logs miss most stops

Many plants estimate downtime rather than measure it. NIST's Machinery Maintenance Survey asked US discrete manufacturers what percent of planned production time is unplanned downtime, and NIST estimates the share at 7.8% across the sector.[1] NIST adds that the survey asks about issues that, "for many firms, are not formally tracked."[1]

A paper log fails in a predictable way. It records the stops someone had time to walk over and write down, and it rounds them. A two-minute jam cleared at the machine never reaches the log sheet.

#### Worked example: One shift on a CNC machining center

- Shift: 06:00 to 14:00 with a 30-minute lunch, so planned production time is 450 minutes.
- The machine signal records 27 stops: a 38-minute changeover, a 22-minute coolant pump fault, a 14-minute wait for material and 24 short stops of 1 to 3 minutes that add up to 48 minutes.
- Measured downtime: 38 + 22 + 14 + 48 = 122 minutes.
- The paper log shows three stops, written as 40, 20 and 15 minutes, for 75 minutes.

The three long stops are on the log, rounded. None of the 24 short stops is.

**Result:** Downtime missing from the log = 122 − 75 = 47 min, 38.5% of the shift’s downtime

Figure: Two bars cover one shift from 06:00 to 14:00. The machine signal shows 27 stops totaling 122 min, including 24 short stops of 1 to 3 min. The paper log shows 3 stops totaling 75 min, so the log comes up 47 min short.

*The same shift, recorded twice: the signal sees 27 stops and the log sees three. Sample data.*

Whether those 48 short-stop minutes count against availability or performance depends on your short-stop cutoff, as [where micro-stops show up in OEE](/blog/micro-stops/#oee) explains. Either way, a paper log can't put them anywhere, because it never saw them.

[Where the missing minutes come from](/blog/manual-vs-automatic-oee-tracking/#missing-minutes) breaks a paper log's gap down by source: rounded times, the shift start and short stops.

## Record the stop automatically

Four methods can record when a machine stops. They differ in what they catch and in how much they ask of the operator.

| | Paper log | Operator button | Machine sensor | Controller connection |
|---|---|---|---|---|
| Records stops under 2 minutes | No | Rarely | Yes | Yes |
| Start and end times | Rounded, from memory | When someone presses | To the second | To the second |
| Operator work per stop | Times and reason | Two presses and a reason | Reason only | Reason only |
| Works on any machine age | Yes | Yes | Yes | No |
| Reads alarm codes | No | No | No | Yes |
| IT review | None | Network only | Network only | Yes, IT usually reviews it first |

A button depends on someone pressing it at both ends of every stop. The two automatic methods don't.

> **Sensor or controller signal?**
>
> Default to a machine sensor for the start and end of every stop, especially when your machines span brands and ages. Add a controller connection where you need what only the control knows, such as alarm codes and the running program. A connection to the controls is a security concern for many plants, so plan for an IT review.

You don't need a controller connection to track downtime. Start time, end time and a reason are the whole record, and a sensor on the outside of the machine supplies the times on any machine. The [sensor and PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) covers what each one sees.

Two settings decide how clean the record is:

- **Separate a stop from a pause in the cycle.** A machining center that pauses 20 seconds to change a tool between parts is running, not down. Set the stop threshold above the longest pause that belongs to the cycle, then check it against a stopwatch over 10 cycles.
- **Keep missing data out of downtime.** When a sensor loses power or its connection, record that time as unknown, not as stopped. Otherwise a sensor unplugged over a weekend reads as 48 hours of downtime. The metrics reference calls this [unknown time](/docs/monitoring/metrics-reference/#unknown).

## Keep the reason list short

> **Definition.** **Downtime reason code** is a short label that an operator or a rule puts on a stop to say why the machine stopped, such as Changeover or Waiting for material, so stopped minutes can be totaled and ranked by cause.

The list decides whether the data is worth reading. An operator facing 40 codes on a touchscreen in the middle of a shift picks the first plausible one. The chart then ranks the order of your list, not the losses on your floor.

Four rules keep a list usable:

- **8 to 12 codes that operators pick**, each named for something a person can fix. `Machine problem` names nothing and wins every month.
- **A planned flag on every code**, set when you build the list, so changeovers and preventive maintenance read apart from failures.
- **A required note only where the code alone says nothing actionable**, such as `Breakdown` and `Other`.
- **An owner for every code**, the person who acts when that code tops the chart.

Split the list by who assigns each code. Rules assign `Short stop`, `Start of shift`, `End of shift` and `Lunch break`. Operators pick the rest, such as `Changeover`, `Waiting for material`, `Tool problem` and `Breakdown`.

A full starter list with severities is in [which reason codes to log](/blog/downtime-reason-codes/#starter-list).

Keep `No job scheduled` apart from the failure codes. A machine with no work is [idle rather than down](/blog/cost-of-idle-machines/#idle-vs-downtime), and the fix lives in the schedule, not on the floor.

## Get a reason without slowing the line

The goal is fewer questions, not faster answers. In the example shift, 24 of the 27 stops were short stops. A rule that labels every stop under a 5-minute cutoff leaves the operator three stops to explain in 8 hours.

Figure: Of 27 stops and 122 min recorded in one shift, a short-stop rule names 24 stops worth 48 min. The operator explains 3 stops worth 74 min: the changeover, the coolant pump fault and the wait for material, 60.7% of stopped minutes.

*The rule takes the many short stops, so the operator answers three questions that hold most of the minutes. Sample data.*

Those three stops hold 74 of the 122 stopped minutes, 60.7%. The operator spends attention where the time is, and the rule handles the rest with no one touching it.

1. **Classify short stops by rule.** Set a cutoff below the shortest stop you want a person to explain, such as 5 minutes. Every stop under it gets `Short stop` from one of the [automatic classification rules](/docs/monitoring/auto-downtime-rules/).
2. **Classify shift edges and breaks by schedule.** Stops at the start and end of a shift, and inside a lunch window, take their reason from the shift calendar. Turn these rules on only after the shifts in your system match the floor, or real downtime gets filed under `Lunch break`.
3. **Ask at the machine while the stop is open.** Put the reason picker at the machine, on a tablet or the machine's own screen. A reason chosen during the stop beats one reconstructed at the end of the shift.
4. **Classify a run of stops at once.** When five stops share one cause, such as a mold wash, select them together and [classify them in bulk](/docs/monitoring/classify-downtime/#bulk). Never clear a backlog by labeling it all `Other`.
5. **Split a stop that holds two causes.** A 90-minute stop where a changeover ran into a breakdown at minute 30 is two records: 30 minutes of `Changeover` and 60 minutes of `Breakdown`.
6. **Alert on stops that run long.** Set a warning above your normal changeover and a critical time well past it, for example 15 and 45 minutes. Someone then walks to the machine while the cause is still in front of them. [Machine Down alerts](/docs/alerts/asset-event-rules/#machine-status) take both thresholds.

You probably don't need an end-of-shift review form. When the picker sits at the machine and rules cover the routine stops, the supervisor's job shrinks to the handful of stops still open at shift change.

## Check the record every day

A downtime record can look complete and still be wrong. Three numbers tell you whether to trust it, and each takes a minute to read at the start of the day.

| Check | What it tells you | Act when |
|---|---|---|
| Unclassified share of minutes | Whether reasons keep up with stops | It stays above 5% after week one |
| Unknown time per machine | Whether the sensor stayed online | Any machine shows unknown time |
| Share of minutes under Other | Whether the list fits the floor | Other passes 10% for a week |

These thresholds are starting points, not standards. Tighten them once the record is stable.

For example, on a 450-minute shift with 122 stopped minutes, 5% is about 6 minutes. If the morning report shows 30 unclassified minutes on one machining center, ask that shift's operator today, while they still remember. Read the notes under `Other` once a week: a cause that repeats there is the next code to add.

## Review the stops every week

A *downtime Pareto* ranks reasons by the minutes they cost, longest first, with a running total. It shows how few reasons make up most of the loss.

Rank by minutes, not by count. In the example shift, `Short stop` is 24 of 27 stops, 88.9%, so a chart by count shows little else.

Ranked by minutes, `Short stop` holds 48 of 122, 39.3%, and the 38-minute changeover sits close behind it. One changeover costs nearly as much as two dozen jams, and only the chart by minutes shows it.

> **Is Unclassified your tallest bar?**
>
> Then the chart ranks missing reasons, not causes. Fix the code list or the rules before you read anything else into it.

Review the chart at a [fixed weekly slot](/blog/downtime-root-cause-review/#agenda), with production, maintenance and the shift leads in the room. Take the top three reasons, give each an owner and a date, and check last week's three against this week's chart.

[Building a downtime Pareto](/blog/downtime-pareto/) works a full week through. The IoTFlows docs show how to read [the Pareto and trend charts](/docs/monitoring/downtimes/#pareto).

Datwyler's injection molding plant in Ontario, California, runs this pattern on more than 20 machines. Automatic rules classify short downtimes and stops at the start and end of each shift, and operators and supervisors classify the rest.

Week over week, the reports showed that Tuesday shift transitions added 8 to 10 minutes of downtime every week. Within six months the plant cut shift-changeover downtime 50% and material-changeover downtime 30%, as [Datwyler's story](/customers/datwyler/) describes.

## Track downtime automatically

A SenseAi sensor mounts magnetically on the outside of each machine and reads its vibration and sound, with no PLC connection. It decides running or stopped every second, so every stop is on the machine's timeline within seconds and no one writes anything down.

Operators put a reason on a stop in a tap, at the machine, in Operator View or in the iOS app. Reason codes sit under severity headings, with required notes and planned flags. Four automatic rules classify short downtimes, shift starts and ends, and a machine down for a whole shift, and break windows cover lunch and breaks.

The Downtimes report ranks reasons by the hours they cost, with trends by interval and by machine. A classified stop can open a Maintain work order from the same dialog. See how the pieces fit on [downtime tracking](/solutions/downtime-tracking/).

## Start tracking downtime this week

1. Enter your shifts and time zone before you read any number, because shift-edge and break rules depend on them.
2. Pick one cell to start, ideally the one that limits output.
3. Record start and end times from a machine signal, and check one shift against a stopwatch.
4. Load 8 to 12 operator reason codes, each with a planned flag and an owner.
5. Turn on the short-stop rule on day one, and the shift-edge rules once the shifts match the floor.
6. Set long-stop alerts above your normal changeover time.
7. Read the three daily checks each morning.
8. After one week, read the Pareto and give the top three reasons an owner and a date.

You don't need OEE to start. Stopped minutes by reason are the input to availability, so a clean stop log makes [calculating OEE](/blog/how-to-calculate-oee/) arithmetic later.

## Questions

### How short a stop should I record?

Record every stop the signal sees, then decide which ones need a person. Pauses that belong to the cycle, such as a tool change, are not stops at all. Set a short-stop cutoff below the shortest stop you want a person to explain, such as 5 minutes, and let a rule label everything under it. Review the short-stop total each week, because hundreds of brief stops can add up to hours.

### Should I track planned downtime too?

Yes. Record changeovers, preventive maintenance and breaks as stops with a planned flag, so you can read them apart from breakdowns. Planned stops still cost hours. A changeover can be the largest single reason on the chart, and shrinking it returns capacity the same way fixing a breakdown does.

### Does an unclassified stop still count as downtime?

Yes. A stop counts in full from the moment the machine stops until it runs again, whether or not anyone has given it a reason. Classifying a stop changes what you can say about the time, not how much of it there is, so a large unclassified share hides causes but never shrinks the total.

### Who should classify a stop, the operator or the supervisor?

The operator at the machine, while the stop is open, because that person saw what happened. Give supervisors the stops left unclassified at the end of the shift and the stops that need a second opinion, such as a breakdown note that names no part. A reason added the next morning is a guess.

## Sources

1. [Economics of Manufacturing Machinery Maintenance: A Survey and Analysis of U.S. Costs and Benefits (NIST AMS 100-34)](https://nvlpubs.nist.gov/nistpubs/ams/NIST.AMS.100-34.pdf), National Institute of Standards and Technology, accessed Oct 16, 2026