Cycle time = total production time ÷ number of units produced. That's the whole formula — there's no deeper math hiding behind it. What trips people up isn't the division, it's deciding what actually belongs in the numerator.
The formula, and the part that's easy to get wrong
Total production time ÷ units produced sounds unambiguous until you have to pick a start and stop point for "total production time." Two people can watch the same machine, apply the same formula, and land on two different cycle times — because one of them is timing spindle-on to spindle-off, and the other is timing start-to-start: the moment one part's cycle begins to the moment the next one does.
Start-to-start is the one that matters. It automatically captures tool changes, load/unload time, in-process gauging, and every short stop that happened in between — not because someone remembered to add them in, but because they occurred inside the window being measured. Spindle-on time leaves all of that out, which is exactly why a spindle-time cycle time usually looks better than the real one.
A common pattern, not a specific install
Illustrative only — a generic pattern, not a customer result.
A supervisor times a cycle with a stopwatch, clicking start at the sound of the spindle spinning up and stop when it winds down. Call it 48 seconds. The controller's own start-to-start figure for the same part comes in at 61 seconds — 13 seconds unaccounted for. Nothing about the stopwatch reading is wrong; it's just answering a narrower question than the one being asked. The 13 seconds is almost always sitting in one of two places: a tool change between operations, or the load/unload step at the start and end of the cycle, neither of which happens while the spindle is turning.
The gap rarely shows up as a dramatic discovery. It shows up as a schedule that keeps running a few minutes behind what the stopwatch number predicted, with nobody able to say exactly why until someone lines the two numbers up side by side.
What's usually missing from a hand-timed cycle time
The same handful of gaps shows up again and again once a controller-measured number is compared against a manual one:
- Tool changes. A 10-second tool change happening several times per part adds up fast, but a stopwatch focused on "the cut" won't catch it.
- Load and unload time. Especially on a manual or semi-automated load station — if the fixture isn't automated, this is often a bigger share of the cycle than the machining itself.
- In-process gauging or measurement steps. A probe cycle or a manual gauge check between operations is real cycle time, even though nothing is being cut while it happens.
- Short, unlogged stops. Chip clears, alarm resets, probe retries — individually too short to write down, collectively large enough to matter.
None of these are exotic. They're just easy to leave out of a number that's being timed by eye instead of measured from the controller.
Cycle time vs. takt time vs. lead time
Cycle time is one of three numbers that get confused for each other on a shop floor, and each answers a different question:
- Cycle time — how long one unit actually takes. Measured.
- Takt time — how often a unit needs to come off the line to meet demand. Calculated from the order book. See the takt time calculator for that side of the comparison.
- Lead time — total elapsed time from order placement to shipment, including queueing, setup, and inspection — a much longer window than cycle time, and a different problem to solve if it's too long.
Cycle time only becomes diagnostic next to one of the other two. On its own it's just a number; set beside takt time it tells you whether the line is keeping up. For the full comparison, see takt time vs. cycle time on a CNC floor.
Why a one-time cycle time study goes stale
A time study measures cycle time at one moment. Tool wear, a fixture swap, or a different material lot can all shift the real cycle time afterward, and nothing about a one-time study catches that — the number on the sheet stays the same while the actual pace quietly drifts.
This is the same gap that shows up in OEE reporting: if the ideal cycle time baked into a Performance calculation is left at its original time-study value, Performance loss starts absorbing drift that has nothing to do with actual machine speed. See how good OEE actually looks on a CNC floor for how that component is supposed to work.
ThingConnect measures cycle time continuously, part by part, straight from controller data — so a creeping cycle time shows up as a trend on the floor long before it shows up as an unexplained dip in a monthly OEE report.
The short version
The formula is one division: total production time ÷ units produced. The only real decision is what counts as "total production time" — and start-to-start, not spindle-on to spindle-off, is the version that actually matches what happened on the floor. Everything else — comparing against takt time, feeding a Performance calculation, catching drift early — depends on getting that one decision right first.
