What is Cycle Time?

Cycle time measures how long it takes for a unit of work to move from active development to production. For engineering teams, it spans the moment a developer starts coding to the moment that code is live. Short cycle times signal a team that moves without accumulating drag; long cycle times signal bottlenecks worth finding.

What is Cycle Time?

Where cycle time lives in the SDLC depends on how your team defines it, but it almost always spans coding, code review, CI pipeline, and deployment. It is one of the four Cycle Time = Timestamp of production deploy - timestamp of first commit (or branch creation) (under the label "change lead time") and correlates directly with how quickly a team can respond to customer needs or production incidents.

A practical reference range from the DORA State of DevOps research: elite-performing teams achieve cycle times under one hour. High performers land under one day. Medium performers take one day to one week. Low performers can take one to six months. Those aren't aspirational targets; they reflect what the top quartile of engineering orgs already ships.

How to Measure Cycle Time

The formula is straightforward:

Cycle Time = Timestamp of production deploy - timestamp of first commit (or branch creation)

In practice, measuring it accurately requires three things. First, consistent definition: every team member and tool needs to agree on the start and end event. Second, git and deployment data joined: you need commit timestamps from your version control system and deploy timestamps from your CI/CD pipeline in the same place. Third, outlier handling: PRs that sit idle for two weeks before review will skew your average. Median cycle time is a more reliable signal than mean.

Most engineering analytics platforms, including Hivel's DORA Metrics feature, pull this data automatically from GitHub, GitLab, or Bitbucket alongside your deploy events so you aren't manually joining spreadsheets.

Cycle Time vs Lead Time

These two terms are frequently confused, and the confusion costs real diagnostic accuracy.

Lead time for changes covers the full journey from ticket creation (or feature request) to production. It includes time in the backlog, planning, and any waiting before a developer picks it up. Cycle time starts when the work is already active.

A team can have a 3-day cycle time and a 3-week lead time. That gap isn't a coding problem; it's a planning and prioritization problem. Treating cycle time and lead time as interchangeable means you'll try to solve a backlog problem by pushing engineers to code faster. Hivel's cycle time vs lead time breakdown covers the distinction in more detail.

Why Cycle Time Matters for Engineering Teams

Cycle time is one of the few metrics that tells you something real about delivery health. Long cycle times don't just slow shipping; they compound. Each day a branch stays open, merge conflicts accumulate. Each day a PR sits in review, the engineer has mentally moved on. The rework cost of a long cycle is higher than the obvious delay suggests.

There's also a quality dimension that often gets missed. Teams that consistently move fast through short cycle times tend to have fewer production incidents, not more. Smaller, more frequent changes are easier to test, easier to review, and easier to roll back. As Sudheer Bandaru puts it: speed and quality don't trade off when the feedback loop is tight; they both improve together.

When cycle time creeps up, the cause is almost never that engineers are working slowly. It's usually review bottlenecks, flaky CI, unclear requirements, or large PRs that nobody wants to touch. Fixing those is an infrastructure and process problem, not a headcount problem.

Platforms like Hivel surface cycle time alongside deployment frequency and PR review time so engineering leaders can see where the drag is accumulating, not just that it exists.