Cycle time = Net Production Time ÷ Number of Units Produced. If a station runs for 450 minutes of actual production time and completes 775 units, cycle time is about 0.58 minutes — roughly 35 seconds — per unit. It's the actual pace a process is running at, not the pace it's supposed to run at (that's takt time).
The formula and a first worked example
Cycle time = Net Production Time ÷ Number of Units Produced
Net production time is the time a station or line was actually producing — scheduled time minus downtime, changeovers, and breaks. It's a measured pace, not a target: cycle time tells you how fast the process actually ran, not how fast it needs to run.
Worked example (illustrative — substitute your own line's data)
A CNC turning station is scheduled for a 480-minute shift. It loses 30 minutes to a single tool-change event and absorbs no other stoppages, leaving net production time of 450 minutes. In that time it completes 775 parts.
| Element | Value |
|---|---|
| Scheduled shift time | 480 min |
| Downtime (tool change) | 30 min |
| Net production time | 480 − 30 = 450 min |
| Units produced | 775 |
| Cycle time | 450 ÷ 775 ≈ 0.58 min/unit |
0.58 minutes per unit is about 35 seconds per unit. That single number is the basis for everything else in this post — converting it to a rate, comparing it to takt time, and tracking what makes it drift.
Cycle time also feeds directly into the Performance factor of OEE (Ideal Cycle Time × Total Count ÷ Run Time) — if you're already tracking availability or OEE, cycle time is the number that connects maintenance data to the production-rate side of the equation.
Cycle time vs takt time vs lead time
These three get used interchangeably on a plant floor, and mixing them up leads to the wrong fix being applied to the wrong problem.
Cycle time is what this post calculates: the actual time a process takes to produce one unit, measured from real production data. It's a result — what's actually happening.
Takt time is the pace you'd need to run at to exactly match customer demand: Takt Time = Available Production Time ÷ Customer Demand. It's a target, not a measurement — derived from a sales number, not a stopwatch. If a line has 450 minutes available and demand calls for 900 units, takt time is 0.5 minutes per unit.
Put the two together and you get the actual comparison that matters: a cycle time of 0.58 minutes against a takt time of 0.5 minutes means the line is running slower than demand requires — it will fall short by the end of the shift unless something changes. A cycle time below takt time means there's slack, not a problem.
Lead time is a different, larger measurement again: the total elapsed time from when an order or unit enters the process to when it comes out the other end — including every minute spent queued or waiting, not just the minutes a machine was actively working on it. A single station can have a cycle time of 35 seconds and still sit in a multi-day lead time if it spends most of its life waiting in a queue between operations. Cycle time measures the work; lead time measures the whole journey, including everything that isn't work.
| Cycle time | Takt time | Lead time | |
|---|---|---|---|
| What it is | A measurement — the actual pace a process is running at | A target — the pace demand requires | A measurement — total elapsed time per unit, including waiting |
| Formula | Net Production Time ÷ Units Produced | Available Production Time ÷ Customer Demand | Time from order/unit entry to finished output |
| Comes from | A stopwatch / production data | A sales or demand number | Every stage a unit passes through, including queues |
| Tells you | How fast the process actually ran | How fast it needs to run to meet demand | How long a unit takes start to finish, work and waiting combined |
A measurement mistake worth checking before you trust the number
At one CNC manufacturer, the cycle time number looked steadily worse than the line actually ran — and the cause wasn't the machine, the operator, or maintenance. It was what counted as a "cycle." Every dry run — a program-proving pass or a first-article check with no salable part coming off the machine — was being left inside net production time, but the parts those dry runs produced weren't counted toward units produced. The clock was running on time that had no matching unit on the other side of the division, so every dry run pushed the reported cycle time number up without a single real production problem behind it.
What actually moves your cycle time number
Cycle time doesn't drift because the math changes — it drifts because net production time shrinks while the unit count doesn't keep pace, or because output slows for reasons that never show up as a formal stoppage.
Unplanned downtime is the most visible driver — every minute of breakdown maintenance comes straight out of net production time, with units produced staying flat or falling, so cycle time rises every time. Changeovers do the same thing in smaller, more frequent doses — a station that changes over four times a shift loses that time four separate times, even if no single changeover looks significant on its own. Micro-stops — the 30-second jams, the material-feed hesitations, the ones nobody logs as a formal stoppage — are often the biggest combined driver of all, because they're invisible to a downtime report but still erase net production time one small bite at a time.
The honest floor observation: when a cycle time number is climbing, the first thing to check isn't the machine — it's what's actually being counted. A rising number almost never means the equipment got slower; it usually means either the gaps between runs got slightly longer or more frequent (stoppages, changeovers, micro-stops nobody's tracking individually), or — as with the dry-run example above — the formula is quietly counting something it shouldn't. Most teams jump straight to "the line is slowing down" and start looking for a mechanical or maintenance cause before checking whether the number itself is even measuring what they think it's measuring.
A second worked example — a full-day, multi-station view
Cycle time reported from a single short window can be misleading in either direction. A fuller picture comes from totaling net production time and units across a longer period.
Worked example (illustrative)
A multi-station assembly line runs two 8-hour shifts, 960 minutes of scheduled time. Across the day it loses 50 minutes to planned changeovers and 25 minutes to an unplanned jam, leaving 885 minutes of net production time. The line completes 1,680 finished units over the day.
| Element | Value |
|---|---|
| Scheduled time (2 shifts) | 960 min |
| Planned downtime (changeovers) | 50 min |
| Unplanned downtime (jam) | 25 min |
| Net production time | 960 − 75 = 885 min |
| Units produced | 1,680 |
| Cycle time | 885 ÷ 1,680 ≈ 0.527 min/unit |
0.527 minutes per unit is roughly 31.6 seconds per unit, or about 113.9 units/hour (60 ÷ 0.527) if you need a rate instead of a per-unit time. A single-shift snapshot — say, just the second shift if it ran into the jam — would show a worse number than the day actually averaged, which is why a full-day or full-week view, not one shift in isolation, is the right level to report cycle time at.
How MachDatum tracks the inputs to cycle time
MachDatum doesn't compute cycle time directly — that's a production-floor measurement, not something that comes out of maintenance records. What it does compute automatically from closed work orders is the maintenance side of why cycle time drifts: downtime hours by asset, MTTR, and MTBF, updated every time a repair work order closes.
Where MachDatum fits: if your cycle time is climbing and the cause is breakdowns or PM slippage — the most common pattern — downtime by asset, MTTR, and MTBF update automatically from work-order history, no spreadsheet or manual re-entry required. We're onboarding our first group of manufacturing teams right now — see how it works at machdatum.com/cmms.
FAQ
How do you calculate cycle time? Cycle time = Net Production Time ÷ Number of Units Produced. Net production time is scheduled time minus downtime, changeovers, and breaks — it measures how fast a process actually ran, not a target pace.
How do you calculate cycling time? Same formula as cycle time — "cycling time" is an informal variant of the same term. Divide net production time by the number of units completed in that time.
How do you find total cycle time across a shift or a day? Total the net production time and the units produced across the whole period — not just one short window — then divide. A single-shift snapshot can be skewed by one stoppage; a full-shift or full-day total gives a more representative number.
How do I convert cycle time to parts per hour? Divide 60 by the cycle time in minutes. A cycle time of 0.527 minutes per unit works out to roughly 113.9 units per hour (60 ÷ 0.527).
