---
title: "What is machine monitoring, and what does it measure?"
description: "Machine monitoring records each machine’s run state, part counts, cycle times, stops and health. See where each signal comes from and what a plant does with it."
category: "Machines and connectivity"
author: "Mahmoud Parto"
published: "2026-10-21"
updated: "2026-10-30"
source_url: "https://www.iotflows.com/blog/what-is-machine-monitoring/"
---
> Question: What does machine monitoring measure, and what does a plant get from it?

## Key takeaways

- Machine monitoring records six things per machine: run state, part counts, cycle times, stops with reasons, unknown time and health.
- Run state decided every second is the base record, because every uptime, downtime and cycle-time number is built from it.
- Unknown time is the gap when a sensor reports nothing, and it belongs in neither uptime nor downtime.
- A sensor, a controller connection and manual entry each deliver different signals, so most plants combine two of them.
- A plant gets measured run time, the stop reasons that cost the most hours and a part count it can schedule against.

Machine monitoring measures what each machine does through the shift: whether it is running or stopped, second by second, how many parts it makes, how long each cycle takes, how long and why it stops, when no data arrived, and how healthy it is. From those records a plant gets measured run time, the stop reasons that cost the most hours and a part count to schedule against.

This guide is for plant managers and owners deciding what to monitor. It defines each signal, shows where each one comes from, and ends with what to monitor first.

## What is machine monitoring?

> **Definition.** **Machine monitoring** is the automatic, timestamped recording of what each production machine does: when it runs and stops, how many parts it makes and how long each takes, why each stop happened, and how its vibration compares with its healthy baseline.

The word that matters is *automatic*. A paper log written at the end of a shift records what someone remembers. A monitoring system records the moment a spindle stops turning, whether anyone noticed or not.

Kentucky’s MEP center splits monitoring into two levels. Basic monitoring uses sensors that show whether machines are running, idle or stopped, and intermediate monitoring adds throughput and cycle counts.[1] The same page puts the cost at a few hundred to a few thousand dollars per machine, with installations usually done within a few days.[1]

The first number most plants read is *uptime*: running time divided by running plus stopped time. The [glossary entry for uptime](/docs/get-started/glossary/#uptime) gives the exact calculation, and [what is machine utilization](/blog/what-is-machine-utilization/) covers how it differs from OEE.

## What signals does machine monitoring record?

Machine monitoring records six signals per machine. Each answers one question, and each has a unit you can check against the floor.

| Signal | Question it answers | Unit |
|---|---|---|
| Run state | Is it running right now? | Running or stopped, each second |
| Part count | How many did it make? | Parts per hour or per shift |
| Cycle time | How long does one part take? | Seconds or minutes per part |
| Stops | How long, and why? | Minutes, with a reason code |
| Unknown time | When was there no data? | Minutes with no report |
| Health | Is the machine wearing? | Vibration against a baseline |

Uptime and downtime are not separate signals. Both are sums of the run-state record inside your shifts.

Figure: One hour on a CNC mill. The run-state bar shows 41 minutes running, a 9-minute tool change, a 2-minute short stop and 8 minutes unknown while the sensor was offline. Twenty part ticks fall one every 2 minutes, and vibration stays steady.

*Five of the six records on one shared clock; cycle time is the gap between part ticks. Sample data.*

### Run state, every second

*Run state* is whether the machine is running or stopped, decided from a physical signal such as vibration, sound, motor current or a passing part. Purdue’s MEP describes the approach: monitoring a machine’s amperage or its vibrational noise lets software determine the machine’s status and track production automatically.[2]

Decide it often enough to see short stops. A system that checks a machine every 15 minutes can miss a 9-minute jam completely, while one that decides each second logs the stop at 10:41 and the restart at 10:43. [How sensors detect machine state](/blog/how-sensors-detect-machine-state/) explains the thresholds behind that decision.

### Part counts and cycle times

A *part count* is the number of cycles the machine completed, multiplied by the parts each cycle makes. A press with a two-out die makes 2 parts per stroke, and a four-cavity mold makes 4 per shot.

*Cycle time* comes from the same record: running time divided by the parts made. In the hour above, 41 running minutes and 20 parts give one part every 2.05 minutes, which rounds to the 2 minutes the ticks show.

### Stops, durations and reasons

A *stop* is any stretch the run state reads stopped. The machine records its start, end and duration on its own. The reason still comes from a person, because a 14-minute stop looks identical in the signal whether the operator was changing a tool or waiting for material.

Operators put a reason code on each stop, and automatic rules can tag routine ones such as short stops or the start of a shift. [Downtime reason codes](/blog/downtime-reason-codes/) shows how to build a list operators will use.

### Unknown time

*Unknown time* is any interval when the monitoring device sent nothing, because it lost power or its network connection. It isn’t a machine state, so it counts as neither running nor stopped.

For example, a sensor unplugged over a weekend produces 48 unknown hours, not 48 hours of downtime. The [unknown time definition](/docs/monitoring/metrics-reference/#unknown) shows how it is kept out of both terms. A lot of unknown time points to a power or Wi-Fi problem, not a production one.

### Machine health

*Machine health* compares a machine’s vibration with its own healthy baseline, so wear shows as drift before it becomes a breakdown. A 2016 NIST paper used low-cost sensors to determine the operating condition of milling machines and to detect anomalies, and noted that older machines can be retrofitted with new sensors.[3]

Health is optional for most machines. Add it where a breakdown stops a line or a repair takes days.

## How do you get data off a machine?

You get data off a machine in one of three ways: an external sensor reads it from the outside, a controller connection reads what the machine’s PLC or CNC control already knows, or a person types it in. Each delivers a different set of signals.

| | External sensor | Controller connection | Manual entry |
|---|---|---|---|
| Run state each second | Yes | Yes | No |
| Part count | Yes | Where the control counts | Shift totals |
| Cycle time | Yes | Yes | No |
| Stop duration | Yes | Yes | Long stops only |
| Stop reason | No | Alarm code only | Yes |
| Unknown time | Yes | Yes | No |
| Vibration health | Yes | No | No |
| Program and alarms | No | Yes | No |

Stop reasons come from operators in every setup. A controller alarm can suggest a reason but doesn’t replace one.

An *external sensor* mounts on the machine and reads vibration, sound or a passing part. It works the same on a 1985 lathe and a new machining center, because it never touches the control. [Monitoring an old machine with no network port](/blog/monitor-old-machines-without-a-plc/) covers where to mount one.

A *controller connection* reads the control over a protocol such as MTConnect or OPC UA. OPC UA, released in 2008, identifies each client and server with X.509 certificates and supports message signing and encryption.[4] Even so, a connection to a PLC or CNC control is a security concern for many plants, and IT usually reviews it first. [MTConnect, OPC UA and Modbus compared](/blog/machine-communication-protocols/) explains each protocol.

*Manual entry* is a person writing down counts, stops and reasons. It is the only source of stop reasons and scrap causes, and the weakest source of times, because nobody logs a 2-minute jam. [Manufacturing data collection](/blog/manufacturing-data-collection/) works one shift through both ways.

> **Which source fits your machines?**
>
> - **Choose an external sensor** for run state, counts, cycle times and health on every machine, of any brand or age, with no access to the control.
> - **Add a controller connection** where you need alarm codes, program names or process values such as spindle load, and IT has approved it.
> - **Keep manual entry** for what only a person knows: the reason for a stop, the cause of scrap and notes for the next shift.

[Sensor-based vs PLC machine monitoring](/compare/sensor-based-vs-plc-machine-monitoring/) sets out what each approach reads, signal by signal, with its sources.

## What does a plant do with each number?

A plant uses each monitoring number for one decision, made by one role. The table pairs them.

| Number | Decision it drives | Who acts |
|---|---|---|
| Uptime by machine | Add a shift, or buy a machine | Plant manager |
| Stop reasons by hours | Which loss to fix first | Supervisor |
| Part count vs shift goal | Whether the shift is on pace | Operator |
| Cycle time by part | Quotes and schedule run rates | Planner |
| Unknown time | Which device or network to fix | Maintenance, IT |
| Health trend | When to plan a repair | Maintenance |

Uptime answers capacity questions before any money is spent. [Storm Power Components](/customers/storm-power-components/) doubled machine utilization across its CNC machines, lasers and presses, and now schedules on real utilization data.

Stop reasons ranked by the hours they cost show where to start. Datwyler’s injection molding plant cut shift-changeover downtime in half and material-changeover downtime by 30% within six months, once every stop carried a reason, as the [Datwyler story](/customers/datwyler/) describes.

Cycle times change what a machine is asked to do. A Michigan MEP client fitted 16 machines with real-time monitoring and cut cycle times from 23 to 19 seconds, with quicker response to problems.[5]

## One shift, read from its records

Here is what the records say about one hypothetical shift on a Haas VF-2 machining center. Breaks are set as planned time, so the shift leaves 450 scheduled minutes.

#### Worked example: One shift on a Haas VF-2 with 450 scheduled minutes

- Run state: 315 minutes running, 105 minutes stopped, 30 minutes unknown while the Wi-Fi dropped.
- Stops: waiting for material 45 minutes, tool changes 30, setup 20 and short stops 10, for 105 minutes.
- Parts: 189 made, at an ideal cycle time of 1.5 minutes.

Uptime is 315 ÷ (315 + 105) = 315 ÷ 420 = 75%. Checked the other way, the stopped share is 105 ÷ 420 = 25%, and 100% − 25% = 75%.

Performance is 189 ÷ (315 ÷ 1.5) = 189 ÷ 210 = 90%. Checked the other way, the actual cycle is 315 ÷ 189 = 1.667 minutes, and 1.5 ÷ 1.667 = 90%.

**Result:** Uptime 75%, performance 90%, top stop reason waiting for material (45 of 105 minutes)

Figure: A 450-minute shift on a Haas VF-2: 315 minutes running, 105 stopped and 30 unknown. Leaving unknown time out gives 315 ÷ 420 = 75% uptime; counting it as stopped gives 315 ÷ 450 = 70%.

*The same shift read two ways: counting unknown time as stopped costs the machine 5 points. Sample data.*

> **Don’t count unknown time as downtime**
>
> Had the 30 unknown minutes been counted as stopped, uptime would read 315 ÷ 450 = 70%, and the machine would take the blame for a Wi-Fi drop. Fix the device or network instead, and keep the two numbers apart.

The useful finding is the 45 minutes of waiting for material. That is a supply problem at the cell, not a machine problem, and no paper log would have timed it.

## Monitor machines with IoTFlows

IoTFlows is a manufacturing intelligence platform that monitors machines with plug-and-play sensors or custom integrations to any PLC, robot or sensor, and turns the data into utilization, downtime, OEE, production scheduling and maintenance workflows.

A SenseAi on each machine decides running or stopped every second on the device, counts parts from the machine’s own cycle and records every stop for an operator to classify in a tap. [Machine monitoring](/platform/machine-monitoring/) works the same on any brand and any age, with no PLC or controller access.

The results read in [five views](/docs/monitoring/overview/#views): the Assets page for the live fleet, the machine page, Downtimes for where the stopped time went, the Advanced Report for a month or quarter, and Canvas for a floor plan with live status.

## What should you monitor first?

Start with run state on the machines that limit output, and add signals only when a decision needs them.

- **Start with run state and stops** when nobody can say how many hours each machine ran last week. Uptime and a ranked list of stop reasons come from the sensor alone, from the first shift.
- **Add part counts and cycle times** once shifts are set and you want to know whether a running machine runs fast enough. Validate each count against ten parts counted by hand first.
- **Add health** on the few machines where a breakdown stops a line, such as the one 5-axis machining center every job passes through.
- **Add a controller connection** when a recurring question depends on what only the control knows, such as which alarm stopped the machine, and IT has reviewed it.
- **You don’t need** every signal on every machine. A manual saw that runs 2 hours a shift needs run state, not health.

Read one week of stops before changing anything. The largest block of stopped time nobody was logging is the first thing to fix.

## Questions

### Do I need a PLC connection for machine monitoring?

No. A sensor on the outside of a machine records run state, part counts, cycle times, stop durations and vibration health with no access to the control. Connect the controller only where you need what it alone holds, such as alarm codes, the active program or a process value, and plan for IT to review that connection first.

### How is machine monitoring different from an MES?

Machine monitoring records what each machine did: when it ran, what it made and why it stopped. An MES manages what the plant should make and how each order ran, with routings, work instructions and genealogy. Monitoring comes first when nobody knows how much the machines run, because every MES report depends on an accurate machine record.

### Is machine monitoring the same as condition monitoring?

No. Condition monitoring tracks the health of a machine, through vibration, temperature or oil, to plan maintenance before a failure. Machine monitoring tracks production: run state, counts, cycle times and stops. One vibration sensor can feed both, since the same signal shows whether a spindle is turning and whether its vibration is drifting from its healthy baseline.

### How accurate is a sensor-based part count?

Check it before you trust it. Run ten parts, count them by hand and compare with the system. A count that reads exactly double or half the real number is a quantity-per-cycle setting, such as a two-cavity mold set to one, and not a fault in the sensor. Fix the multiplier and validate again.

## Sources

1. [Enhance Your Existing Equipment with Machine Monitoring](https://louisville.edu/servicecenters/news/enhance-your-existing-equipment-machine-monitoring), University of Louisville Service Centers (Kentucky MEP), accessed Oct 27, 2026
2. [Is Legacy Equipment Slowing You Down?](https://mep.purdue.edu/news-folder/is-legacy-equipment-slowing-you-down/), Purdue Manufacturing Extension Partnership, accessed Oct 27, 2026
3. [Machine Condition Detection For Milling Operations Using Low Cost Ambient Sensors](https://www.nist.gov/node/1268861), National Institute of Standards and Technology, accessed Oct 27, 2026
4. [Unified Architecture](https://opcfoundation.org/about/opc-technologies/opc-ua/), OPC Foundation, accessed Oct 27, 2026
5. [M R Products, Inc: Technology Adoption Improves Data, Capacity & Quality](https://www.nist.gov/node/1741691), National Institute of Standards and Technology, Manufacturing Extension Partnership, accessed Oct 27, 2026