Cycle Time

Cycle time in software development is how long it takes from when a developer starts on a piece of work to when that work is finished and merged into the main codebase. It covers everything: writing the code, waiting for a reviewer to pick it up, going through review, making any changes requested, and finally getting it approved. It is a direct measure of how efficiently the team moves individual changes through their process.

Cycle time is one of the most actionable measures in engineering because it surfaces bottlenecks that are hidden at the feature level. A feature may take three weeks to deliver, but if each individual piece of work has a cycle time of five days, the problem is not the scope -- it is friction in the process. Breaking down delivery time into individual cycle times shows exactly where time is being spent and, more importantly, where time is being wasted.

Cycle time ends at merge; lead time for changes (a DORA metric) extends all the way to when the code is live in production. For teams that deploy automatically, the difference is minutes. For teams with manual release steps, approval gates, or staging environments, the gap between cycle time and lead time can be days or weeks. Both measures matter, but they diagnose different parts of the delivery process.

Why Cycle Time Matters

Cycle time matters because it is the tightest feedback loop available to engineering teams. Short cycle times mean developers learn quickly whether their code works, reviewers catch issues while context is fresh, and the team can iterate rapidly on solutions. Long cycle times mean context-switching, stale reviews, merge conflicts, and delayed feedback that compounds into wasted effort.

For non-technical managers, cycle time is perhaps the single most intuitive engineering metric. It answers the question: when a developer starts working on something, how long until it is done? If the answer is consistently several days or more for typical changes, something in the process is slowing the team down. Cycle time gives managers a specific, measurable signal to discuss with engineering leads without needing to understand the technical details of what is being built.

How to Measure Cycle Time

Cycle time is calculated per pull request as the difference between the first commit timestamp and the merge timestamp. Teams typically track the median and 75th percentile (P75) across all pull requests in a given time period. The median gives a sense of typical performance, while the P75 reveals how often the team experiences outlier delays.

When breaking down cycle time into its components, most teams find that coding time (first commit to PR opened) is a small fraction of total cycle time. The majority of time is typically spent in two phases: time to first review (how long the PR waits before anyone looks at it) and rework time (how long between review comments and the final approval). This breakdown is critical because it tells you whether the bottleneck is review availability or code quality.

Common Mistakes When Tracking Cycle Time

The most common mistake is averaging cycle time across all pull requests without accounting for PR size. A 10-line bugfix and a 500-line feature refactor should not be evaluated against the same benchmark. Smart cycle time analysis segments by PR size and type, comparing similar work items rather than conflating trivially different changes.

Another mistake is treating cycle time as a target to minimize at all costs. Extremely short cycle times can indicate that reviews are being rubber-stamped, that changes are trivially small, or that quality checks are being skipped. A healthy cycle time reflects thorough review and adequate testing, not just speed. The goal is to eliminate unnecessary waiting time while preserving the review quality that catches bugs before they reach production.

Related Metrics

Cycle time is closely related to lead time for changes, which extends the measurement from merge to production deployment. Together, they show whether the bottleneck is in the development process (high cycle time) or the deployment pipeline (large gap between cycle time and lead time). Developer velocity uses cycle time as one of its component signals. Engineering team health incorporates cycle time trends alongside collaboration and sustainability indicators.

Benchmarks from industry research suggest elite teams maintain median cycle times under one day, high performers range from one to three days, and teams exceeding five days should investigate their review process, PR sizing practices, and work-in-progress limits.

Key Takeaways

• •Cycle time measures elapsed time from first commit to merge -- the tightest feedback loop in engineering.
• •Most cycle time is spent waiting for reviews, not writing code.
• •Elite teams achieve median cycle times under one day; high performers range from one to three days.
• •Cycle time differs from lead time for changes: cycle time ends at merge, lead time extends to production deployment.
• •Segment cycle time by PR size to get meaningful benchmarks -- do not average trivial fixes with major refactors.

How CodeVitals Helps

CodeVitals tracks how long each piece of work takes from start to finish across your GitHub repositories. The dashboard shows you where time is going -- whether work is sitting idle waiting for a reviewer, or taking a long time in back-and-forth after review -- so you can see exactly where the slowdown is. Managers get a plain-language summary of whether the team's pace is healthy, along with specific coaching recommendations on what to improve.

Related Reading