What is Cycle Time? PR Cycle Time vs. Lead Time, Explained
June 2, 2026·7 min read·by Ihab Hamdy
"Cycle time" is one of the most overloaded terms in engineering measurement. Depending on who's talking, it can mean three different things. This guide pins down each one — and shows you which to track for which problem.
What is cycle time?
In its broadest sense, cycle time measures the elapsed time from when work starts to when it is finished. The boundaries of "start" and "finish" are exactly what causes the confusion — different teams draw them in different places.
DORA Metrics Calculator
Benchmark your cycle time
Definitions are useful; your number is better. Enter your four DORA dimensions and see your tier against the 2025 State of DevOps benchmarks.
Here are the three definitions you'll encounter, from narrowest to broadest:
PR cycle time — from a pull request being opened to it being merged. The narrowest and most actionable. It breaks down into pickup time, review time, and the gap before merge.
Lead time for changes — from a commit to that change running in production. A DORA metric; PR cycle time is a slice of it. See what is lead time.
Delivery cycle time — from work starting (first commit, or ticket moved to "in progress") to it being shipped. The broadest, and the hardest to measure consistently.
When each one matters
Reach for the metric that matches the question you're asking:
"Why is review slow?" → PR cycle time. It isolates the review bottleneck better than anything else.
"How fast do we get value to users?" → lead time for changes. This is the one to report to leadership.
"Where does work stall across the whole flow?" → delivery cycle time, if you can measure it reliably.
PR cycle time benchmarks
Because PR cycle time is the most actionable, it's the one worth benchmarking first. Against the DORA-aligned tiers:
Elite: 4 hours or less
High: 24 hours or less
Medium: 24–72 hours
Low: More than 72 hours
Elite
4 hours or less
High
24 hours or less
Medium
24–72 hours
Low
Over 72 hours
PR cycle time tiers, from pull request opened to merged — the narrowest and most actionable slice of lead time.Source: DORA-aligned tiers, 2024 State of DevOps Report.
A stale PR sitting for days is the single most common reason teams land in the Low tier — and the easiest to fix once you can see it.
How to track cycle time
You can get an instant read on your team's PR cycle time — median and P75, broken into phases — with the free PR cycle time calculator. For continuous tracking, an engineering intelligence platform like Deviera computes PR cycle time per repo automatically from your GitHub events, ties it back to lead time and the rest of DORA, and flags stalled PRs before they block the sprint.
PR cycle time is the elapsed time from a pull request being opened to it being merged. It is the narrowest and most actionable of the three 'cycle time' definitions, and it breaks down into three phases: pickup time (open to first review), review time, and the gap before merge. Because it isolates the review bottleneck better than any other metric, it's the one worth benchmarking first — against DORA-aligned tiers, Elite is 4 hours or less, High 24 hours or less, Medium 24–72 hours, and Low more than 72 hours.
What is the difference between PR cycle time and lead time?
PR cycle time runs from a pull request being opened to merged; lead time for changes runs from a commit to that change running in production. PR cycle time is a slice of lead time — the most actionable slice — while lead time for changes is the full DORA pipeline measure you'd report to leadership. Use PR cycle time to answer 'why is review slow?' and lead time for changes to answer 'how fast do we get value to users?'
