Takt time is the pace demand requires. Cycle time is the pace the machine is actually running at. Most of the confusion between the two comes from treating them like two names for the same thing, when really you're supposed to put them side by side and read the gap.
What each one actually measures
Takt time = net available production time ÷ customer demand for that period. It's arithmetic from the order book and the shift schedule, nothing more. A 450-minute shift against a 900-unit order gives 0.5 minutes (30 seconds) per unit. The machine itself never enters that number. You'd get the same takt time whether the part takes 20 seconds to machine or two minutes.
Cycle time is the opposite kind of number. It's measured, not calculated: how long the machine actually takes, start to start, to turn out one part. Spindle time, tool changes, loading and unloading, whatever happens between one part finishing and the next.
Line them up and it's not complicated:
- Cycle time longer than takt time: the machine can't keep up with demand.
- Cycle time shorter than takt time: there's slack, or demand is being over-served.
- Cycle time close to takt time: the line is paced about right for what's being asked of it.
The takt time calculator gives you the demand-side number, the cycle time calculator the machine-side one. Read them together. Either on its own doesn't tell you much.
Why matching them is the whole game
A takt time by itself is just arithmetic. A cycle time by itself is just a stopwatch reading. The comparison is the point — the gap is what tells you whether a schedule is achievable with the equipment you actually have.
Both numbers also move more than people expect. Takt time shifts whenever the order does: a rush order, a smaller batch, an extra shift all change the denominator or the available time. Cycle time shifts whenever the process does: tool wear, a fixture swap, a different material lot. Do the comparison once at the start of a job and it's stale the moment either side changes. That's really the whole case for reading cycle time continuously off the controller instead of from a one-time time study — the comparison has to survive the job changing underneath it, not just describe the day someone measured it.
A worked example
This happened at a recent installation at a Tier-1 automotive casting supplier. Three CNCs in sequence, Machine 1 feeding Machine 2 feeding Machine 3, all machining an aluminium-casting infotainment bracket. On a line like this, takt time cascades backward: Machine 3's takt time comes straight from the customer commitment, Machine 2's is set by what Machine 3 needs fed into it, and Machine 1's is set by what Machine 2 needs in turn.
Shift quota was 120 units, so each station needed a takt time of 15 minutes. Machine 2's measured cycle time — spindle time alone — came in at 13 minutes, comfortably under takt by the number everyone was actually watching. Except that number didn't include the 2.5 minutes of handling per part: load, unload, and an in-process measurement step on tooling shared with the next station. Add that in and the real time per part was 15.5 minutes. Half a minute over takt, and invisible for as long as "cycle time" quietly meant spindle-on time and nothing else. It's the same mistake as "ignoring changeover time because it's not cutting" further down — just handling and shared tooling standing in for a tool change.
It took three days to catch, and how it surfaced is its own lesson. During the shift, the operator could see the machine sitting idle more than it should, but nobody writes down a 45-second stop or a two-minute one on a paper logbook, so there was no record of why output was slipping — only that it was. At end of day a supervisor transcribed the operator's log into a spreadsheet and saw the shortfall with no explanation attached to it. It took the weekly production meeting, with several days of shortfall stacked against a missed delivery date, before anyone traced it back to Machine 2 and the double-counted handling time. The fix was a process change to the shared-tooling step. By then a shipment had already gone out late.
What to check when cycle time creeps above takt
The gap doesn't tell you why. It just tells you to go look, usually in this order:
- Tool wear. A worn insert or drill adds seconds per part a little at a time — exactly the kind of drift a one-time time study at job start-up will never catch.
- Unlogged micro-stops. Chip clears, probe retries, short alarms. None of it makes it onto a paper downtime log, but it's sitting inside the cycle-time number whether anyone wrote it down or not.
- A changed fixture or material lot quietly adding setup or cut time the program was never tuned for.
- Nobody revisited the rated cycle time after a program edit, so "performance loss" on an OEE report is really just an out-of-date baseline.
Takt time won't show any of this — it's demand-side, it doesn't move for tool wear or a bad fixture. The diagnosis is always on the cycle-time side.
Common mistakes when comparing the two
The same handful of errors shows up again and again once a floor starts tracking both numbers.
Treating takt time as a speed target for the machine. It isn't. It's a schedule requirement, not a speedometer. A machine running faster than takt time isn't "ahead" — it's over-producing against what was actually ordered, and that can tie up capacity a different part needs.
Averaging cycle time across a part family that actually varies. A part with three fixture positions and one with a single fixture don't share a cycle time just because they share a part number prefix. Average them together and you hide whichever one is actually behind.
Recalculating takt time but not cycle time, or the other way round. Takt time moves the instant an order changes mid-shift — it's arithmetic. Cycle time only "moves" when someone goes and re-measures it. Comparing a fresh takt time against a cycle-time number from last week's time study isn't really comparing anything; it's two different moments pretending to be the same gap.
Ignoring changeover and tool-change time because it's "not cutting." Cycle time is start-to-start, not spindle-on to spindle-off. A program that machines fast but tool-changes slowly can still blow past takt time without a single part running slow.
Checking the gap once a shift instead of continuously. An end-of-shift comparison tells you the job missed takt. It won't tell you when it started missing, which is the part that actually points at a cause.
Takt time at the line level vs. a single machine
Everything above assumes one machine against one order, which is also how the takt time calculator is scoped. A multi-machine cell has one line-level takt time, driven by total demand for the finished part, but every station in that line has its own cycle time — and the slowest one sets the ceiling for the whole line no matter how fast the rest run.
Find that bottleneck station deliberately rather than by elimination. The station whose cycle time sits closest to the line's takt time (or above it) is the one to instrument first. Everything else already has margin to spare.
Cycle time vs. lead time — a different pair entirely
Cycle time and lead time get confused about as often as takt and cycle do, but they're not adjacent measurements — they're different scopes of the same job.
Cycle time, like takt time, is about the pace of production: how long one unit takes, how often one comes off the machine. Lead time is the total elapsed time from order placed to order shipped — queueing, setup, machining, inspection, packing, all of it.
A line can hit its takt time exactly, one part every 50 seconds on schedule, and still carry a two-week lead time if the part sits queued for days before it ever reaches the machine. Shortening lead time is usually a queue-and-changeover problem. Closing a takt gap is a process problem. Mix the two up and you end up investigating the wrong half of the floor.
Where this connects to OEE
The takt-vs-cycle comparison is really a preview of the Performance component of OEE — see the full OEE guide for how Performance sits alongside Availability and Quality. Cycle time drifting above takt is Performance loss showing up before it ever reaches a weekly OEE report. Catch it at the takt-vs-cycle stage and you've caught it a full reporting cycle earlier than most floors do.
Want to see this run against your own shift numbers, pulled straight from the controller instead of a spreadsheet? Talk to us about what that looks like on your machines.
The short version
Takt time comes from the order book. Cycle time comes from the machine. Neither is wrong when they disagree — disagreement is the normal state, because orders change and tooling wears and fixtures get swapped. What matters is whether someone's actually comparing the two often enough to catch the gap while it's still small. A time study done once at job start-up answers that question for a single moment. A comparison that keeps running as the shift does answers it for the whole job, and that's the gap between noticing a missed takt time at the end of the shift and catching it while there's still time to do something about it.
