How do you calculate cycle time?

Measure the elapsed time from the start of work on one unit to the start of work on the next unit at the same process. Timing many consecutive cycles and averaging is standard — but record the spread too, since variation matters as much as the mean. Cycle time can also be calculated as production run time divided by units produced.

What is the difference between cycle time and takt time?

Cycle time is measured — the pace your process actually achieves. Takt time is calculated — available time divided by customer demand, the pace you need. A healthy station runs its cycle time comfortably below takt; when cycle time exceeds takt, the line falls behind demand every cycle.

How do you find the bottleneck on a production line?

Find the station with the highest effective cycle time — raw cycle time adjusted for downtime and rework. On the floor it's usually visible: WIP piles up in front of it, stations after it sit starved, and it runs constantly while others have idle moments. Verify with data, because the intuitive answer is often wrong.

What is effective cycle time?

Raw cycle time adjusted for availability and quality losses. A station cycling at 50 seconds that's down 15% of the time behaves like a 59-second station. Effective cycle time is the number to compare against takt, and it's why the bottleneck isn't always the slowest-cycling machine.

How many cycles should you time in a cycle time study?

At least 10–30 consecutive cycles per station as a floor — enough to see variation, not just an average. Time them consecutively rather than skipping messy cycles, and repeat on other shifts. For an ongoing picture, automatic capture from machine signals replaces sampling entirely by logging every cycle.

Is lower cycle time always better?

No. Cycle time only needs to sit comfortably below takt time; pushing a non-bottleneck station faster just builds WIP in front of the constraint. Speeding up a station past what demand requires spends money and often quality for output the line can't use. Improve the bottleneck; balance the rest.

Cycle Time: How to Measure It and Find the Real Bottleneck

What the stopwatch misses, what the machines already know, and how to spot the station that sets your pace.

Cycle time is the actual time it takes to complete one unit at a process — commonly measured from the start of work on one unit to the start of work on the next. If a filler starts a new case every 45 seconds, its cycle time is 45 seconds, regardless of what the routing standard claims.

Cycle time is the most fundamental measurement in lean manufacturing, because nearly every other line-level number — capacity, staffing, whether you can meet demand — is built on top of it. It is also one of the most commonly wrong numbers in a plant, because it gets measured once, under ideal conditions, and then trusted for years. This post covers how to measure it properly, how it relates to takt and lead time, how to find the real bottleneck, and why automatic capture from machines beats the clipboard-and-stopwatch study.

Cycle Time vs. Takt Time vs. Lead Time

Quick version: cycle time is what your process does, takt time is what the customer requires, and lead time is what the customer experiences. Cycle time is measured at a single process in seconds or minutes per unit. Takt time is calculated — available time divided by demand — and serves as the target your cycle times have to fit under. Lead time runs order-to-delivery and includes all the waiting between processes, which is why it's measured in days while cycle times are measured in seconds. The full comparison, with a worked takt example, is in our takt time guide. The relationship that matters here: a line keeps pace only when every station's cycle time sits comfortably below takt. Which raises the real questions — what are your cycle times, actually, and which station is the ceiling?

How Do You Measure Cycle Time?

You measure cycle time by defining exact start and stop points, timing many consecutive cycles at each station, and recording the variation — not just the average. The sequence:

Define the start/stop trigger precisely. Start-of-work to start-of-work is the standard, because it automatically includes load/unload time. "When the part hits the fixture" is a trigger; "when the operator starts working" is an argument.
Measure per station, per product. A line has one takt but many cycle times — one per station, and they usually differ by product or size run on the same equipment. Record which product you're timing.
Time at least 10–30 consecutive cycles. One cycle tells you nothing; the interesting information is in the spread. Time them consecutively rather than cherry-picking clean cycles — the jams and fumbles are data, not noise.
Split machine time from operator time from waiting. A 50-second cycle that is 20 seconds of machining and 30 seconds of walking to get parts is a layout problem, not a machine problem. The split tells you which fix applies.
Record the variation, not just the mean. A station averaging 40 seconds with a range of 35–45 behaves completely differently from one averaging 40 with a range of 25–90. Planning on the average of a high-variation station is how schedules quietly fail.
Chart cycle time by station against takt. This is the line-balancing chart below — the single most useful picture of a line's health.
Re-measure on other shifts, or automate. Cycle times drift by shift, operator, tooling wear, and season. A study from one Tuesday morning ages fast — which is the argument for capturing cycles continuously from the equipment itself.

A line-balancing chart with hypothetical numbers: five station cycle times against a 60-second takt. Station 3 is the constraint.

How Do You Find the Real Bottleneck?

The bottleneck is the station with the highest effective cycle time — and that is not always the station with the highest raw cycle time. Effective cycle time folds in reliability and yield: a station cycling at 50 seconds but down 15% of the time behaves like a 59-second station, and if 5% of its output needs rework, worse still. A raw line-balancing chart can point at the wrong station if one machine's downtime is doing the real damage.

The floor evidence usually agrees with the math. Look for:

WIP piling up in front of one station while stations after it sit starved. Inventory accumulates behind constraints the way traffic accumulates behind a slow truck.
The station that never rests. Non-bottleneck stations have idle moments; the constraint runs flat-out and still can't keep up.
Where overtime comes from. If the line consistently needs extra hours to make the schedule, trace which station's shortfall drives it. It's worth noting that U.S. manufacturing production employees average around 3 hours of overtime per week (BLS, Manufacturing: NAICS 31-33) — in many plants, that overtime is quietly funding the gap between the bottleneck's effective cycle time and takt.
What happens when it stops. A minute of downtime at the bottleneck is a minute of lost output for the entire line — unrecoverable without overtime. A minute lost elsewhere often disappears into slack.

One warning: bottlenecks move. Fix Station 3 and Station 2 becomes the constraint; change the product mix and it moves again. Bottleneck identification is a recurring measurement, not a one-time diagnosis.

Why Machine-Data Capture Beats a Stopwatch Study

A stopwatch study samples a few dozen cycles on one day with an observer standing there; automatic capture from the equipment records every cycle, every shift, with nobody watching. The difference shows up three ways:

Sample size. Thirty timed cycles versus tens of thousands of logged ones. The rare-but-expensive events — the jam that takes eight minutes, the slow warm-up cycles after every break — are precisely the ones a small sample misses.
The observer effect. Lines run differently when someone with a clipboard is standing there. Everyone who has done time studies knows this; nobody can fully correct for it.
Drift detection. Cycle times creep as tooling wears and methods erode. Continuous capture turns that creep into a visible trend line; a stopwatch study from last year turns it into a surprise.

Practically, this means pulling cycle timestamps from PLC signals and sensors rather than transcribing them by hand — computing performance from the source instead of estimating it. This is the approach Harmony takes when it connects machines and systems into one operational layer: every input on the floor feeds the platform, so true OEE and real cycle behavior are computed from source signals, not reconstructed from paper at the end of the shift. No rip-and-replace of the equipment — the machines already know their cycle times; the job is capturing what they know.

The stopwatch still has a place: understanding why a cycle takes as long as it does — the walking, the reaching, the waiting inside the cycle — requires standing there and watching. Use machine data to find which station and which shift deserve attention; use direct observation to design the fix.