SOLVETUTORMATH SOLVER

Instrument MI-06-083 · Everyday life

Cycle Time Calculator

Enter net production time and units produced, and this instrument returns the average cycle time per unit, in minutes.

Instrument MI-06-083
Sheet 1 OF 1
Rev A
Verified
Type 06 — Productivity SER. 2026-06083

Cycle time per unit (min)

4.000

cycle time = net production time / units produced

The working Every figure verified twice
  1. cycleTimeMin = 480 ⁄ 120 = 4.000
Worksheet log
  1. No entries yet — change an input to log a scenario.

How this instrument works

Cycle time, takt time, and lead time get confused constantly, but each answers a different question. Cycle time is how long a process actually takes to produce one unit, measured from real output — it describes what's really happening on the line right now. Takt time is a target pace derived from customer demand: available production minutes divided by customer orders, which tells you how fast the line would need to run to exactly meet demand. Lead time is the full span from order placement to delivery, including any wait before production even starts. This calculator computes cycle time only.

The formula used here is the simple, direct method: cycle time equals net production time divided by units produced over that span. "Net production time" is up to you to define for your context — some teams use the full shift length, others subtract planned downtime like breaks and changeovers first to get a more accurate running figure; either way, dividing by units produced gives the average pace per unit for whatever window you enter.

Cycle time is one of the most closely watched metrics on a production floor because it's the fastest way to spot a bottleneck: compare cycle time station by station along a line, and whichever station is slowest is capping how fast the entire line can run, regardless of how efficient every other station is.

C=TNC = \dfrac{T}{N}
T — net production time in minutes (however you define "net" for your process: total shift time, or time with planned downtime already subtracted). N — units produced during that time. C — average cycle time per unit, in minutes.
  • Enter the net production time in minutes (an 8-hour shift, for example, is 480 minutes).
  • Enter the number of units produced in that time.
  • Read the cycle time per unit, in minutes.
  • Compare the result against your takt time (the pace customer demand requires) to see whether the process is keeping up.

Worked example — an 8-hour shift producing 120 units

A production line runs for a full 8-hour shift (480 minutes) and produces 120 finished units in that span: cycle time = 480 ÷ 120 = 4.000 minutes per unit exactly — the average pace at which a finished unit came off the line.

Compare that against, say, a takt time of 3.5 minutes per unit (calculated separately from customer order volume): a 4-minute cycle time running slower than that target means the line is currently falling short of demand and would need a process improvement, an added shift, or a bottleneck fix to close that 0.5-minute-per-unit gap.

Questions

What's the difference between cycle time and takt time?

Cycle time measures how fast a process is actually producing right now, calculated from real output (production minutes ÷ units made). Takt time is a target derived from customer demand — available minutes ÷ number of orders — telling you how fast you'd need to produce to exactly match what customers want, with no more and no less. A healthy line generally wants cycle time at or below takt time; if cycle time consistently runs slower than that target, the process can't keep up with demand.

Should I include downtime in the production time I enter?

It depends on what question you're trying to answer. Including the full shift length (downtime and all) gives an "as-experienced" cycle time that reflects real-world output per shift. Subtracting planned downtime first (breaks, scheduled maintenance, changeovers) gives a "running" cycle time that better reflects the process's raw speed when it's actually operating — useful for comparing the process itself against a different process, separate from how much uptime it happened to get.

How do I reduce cycle time on a bottleneck station?

Common approaches include breaking a long single task into parallel sub-steps run by more than one operator or machine, eliminating non-value-added motion or waiting within the step, upgrading or better-maintaining equipment at that specific station, and standardizing the work method so every cycle runs as close to the fastest observed pace as possible rather than varying. Because a bottleneck station sets the pace for the whole line, improvements focused there tend to have the largest overall impact.

Should I measure cycle time per station or for the whole line?

Both, for different purposes. Per-station cycle time is what reveals bottlenecks — the slowest individual station caps the whole line's output regardless of how fast the others run. Whole-line cycle time (using total units shipped and total production minutes) gives the overall throughput figure that matters for capacity planning and customer commitments, but it hides which specific station is holding things back.

What counts as a "good" cycle time?

There's no universal good number — it depends entirely on the product, process complexity, and what your takt time (customer demand pace) requires. A cycle time is "good" when it reliably meets or beats that target with consistent, repeatable timing across cycles; a process that's fast on average but wildly inconsistent cycle to cycle is often a bigger operational problem than one that's merely slower but steady.

References