PlantOps BI

KPI Library / Production

Cycle Time

Formula: Run time ÷ units produced
Typical range: Actual cycle time within 5 to 10% of engineered ideal is healthy; wider variance points at process instability

Cycle time is the actual elapsed time to complete one unit or one cycle of a process, measured from the start of one unit to the start of the next. It is the inverse of throughput rate, and it is the number an industrial engineer sets a standard against when they build the line in the first place.

What good looks like

There’s no universal “good” cycle time in seconds, because every part, every line, and every process has a different engineered ideal. The number that matters is how close actual cycle time tracks to that ideal. A line running within 5 to 10% of its engineered cycle time is stable and predictable. Wider swings, especially widening swings over time, mean something in the process is degrading: tooling wear, operator fatigue, minor stops that never get logged as downtime.

The trap is treating a falling average cycle time as automatically good. If the ideal cycle time itself keeps getting revised upward by engineering to match whatever the line is actually doing, the metric quietly stops measuring anything. Track cycle time against a version-controlled standard, not a moving target.

Cycle Time in Power BI (DAX)

With an hourly production fact carrying run seconds and units produced, joined to a part dimension carrying the engineered ideal:

Actual Cycle Time (sec) =
DIVIDE (
    SUM ( fact_production_hourly[run_seconds] ),
    SUM ( fact_production_hourly[units_produced] )
)

Ideal Cycle Time (sec) =
AVERAGEX (
    fact_production_hourly,
    RELATED ( dim_part[ideal_cycle_time_sec] )
)

Cycle Time Efficiency % =
DIVIDE ( [Ideal Cycle Time (sec)], [Actual Cycle Time (sec)] )

Trend Cycle Time Efficiency % by shift and by line. A line that’s efficient on day shift and degrades on nights is telling you where to look before the number shows up in OEE.

Common mistakes

  1. Comparing cycle time across different part numbers. A changeover to a smaller or simpler part will always look like a productivity win even though nothing about the process improved.
  2. Letting the ideal cycle time drift with actual performance. If engineering revises the standard every time the line misses it, the metric becomes self-fulfilling.
  3. Ignoring micro-stops inside the cycle. Short stops under a minute rarely get logged as downtime, but they inflate actual cycle time and get blamed on “slow running” instead of the real cause.