Most engineering leaders are surprised to find that code sits waiting for review longer than it takes to write it. PR cycle time measures exactly that: the total elapsed time from when a pull request is opened to when it is merged. When this number is high, your delivery pipeline slows, your squad carries context longer than necessary, and sprint commitments slip. This page covers the definition, how to measure it, industry benchmarks, how to improve it, and how DevStats surfaces it automatically.
Key takeaways
- PR cycle time measures the elapsed time between a pull request being opened and it being merged. It is one of the clearest signals of how efficiently your squad moves code from written to shipped, and a direct input into your team's overall delivery speed.
- PR cycle time is calculated as: time of merge minus time of PR open. Elite engineering teams consistently achieve a median PR cycle time under 24 hours, according to DORA State of DevOps research. Anything above 3 days signals a meaningful bottleneck in your review process.
- The most common mistake teams make is treating a high PR cycle time as a people problem rather than a process problem. Long cycle times almost always trace back to PR size, unclear reviewer assignment, or insufficient review bandwidth, not individual player effort.
- DevStats tracks PR cycle time automatically by connecting to your Git provider, with breakdowns by squad, PR size, and review stage, benchmarked against 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.
PR cycle time definition
PR cycle time is the total time a pull request spends open before it is merged. It starts when the PR is created and ends when it is merged into the target branch. This metric captures the full review and iteration loop, including time waiting for a reviewer, time spent addressing feedback, and time in any approval queue.
The formula is straightforward: PR cycle time = merge timestamp minus open timestamp. In practice, you want to look at the median across all PRs in a given period rather than the mean, because a few very large or blocked PRs will skew an average significantly. When PR cycle time is high, it directly delays your team's throughput and compresses the time available for testing and deployment before a release window closes.
Why PR cycle time matters for engineering teams
When squads do not track PR cycle time, slow reviews become invisible. A player finishes a feature, opens a PR, and then waits. That wait is rarely captured in a sprint retrospective because it does not show up as a task. It accumulates quietly, and by the time a sprint misses its target, the root cause is buried under a week of context switching and stale branches.
PR cycle time connects directly to the KPIs engineering leaders are measured on: on-time delivery, release cadence, and developer satisfaction. Players who routinely wait days for reviews report lower engagement and spend more time re-orienting to their own code after the feedback finally arrives. Teams that track PR cycle time in DevStats get a breakdown by review stage, so a leader can see whether the delay is in the first review, in iteration, or in final approval. That distinction changes the intervention entirely.
PR cycle time is a direct component of the DORA "lead time for changes" metric, which measures the time from code commit to production. Measurement is the first step. The engineering manager is the one who decides what to change.
How to measure PR cycle time
To calculate PR cycle time, you need timestamped data from your Git provider: specifically, the PR creation time and the merge time for every pull request. GitHub, GitLab, and Bitbucket all expose this via their APIs. You calculate the elapsed time for each PR, then take the median across your chosen time window, typically a two-week sprint or a rolling 30-day period.
Useful segmentations include PR size (lines changed), squad, repository, and author. Size matters because a 1,500-line PR will naturally take longer to review than a 50-line PR. Comparing cycle time without controlling for size can mislead. You can find peer-based context through DevStats benchmarks, which show how your team's numbers compare to similar engineering organizations.
No single published standard defines PR cycle time tiers the way DORA defines deployment frequency, but industry data from DORA research and engineering analytics platforms provides a consistent directional picture. Benchmarks vary by team size, codebase complexity, and release model.
| Performance level | PR cycle time benchmark | What it signals |
|---|---|---|
| Elite | Under 24 hours | Reviews are fast, PRs are small, ownership is clear |
| High | 1 to 3 days | Healthy process with occasional review delays |
| Medium | 3 to 7 days | Review bandwidth is constrained or PRs are too large |
| Low | Over 7 days | Significant bottleneck; delivery risk is high |
PR cycle time in practice: a real example
A VP of Engineering at a 40-person SaaS company noticed that sprint velocity had been declining for two consecutive quarters even though the squad was not reporting capacity issues. She pulled PR cycle time data and found the median had crept from 1.8 days to 5.4 days over six months. The data showed the delay was concentrated in the second review stage, after the first round of feedback was addressed. Reviewers were not returning for a second pass within a reasonable window.
She made one process change: she set an explicit team norm that second-review turnaround should happen within four business hours, and she made review assignments explicit rather than left to volunteers. Three sprints later, median PR cycle time had dropped to 2.1 days, and the squad's sprint completion rate recovered. She tracked the change using PR cycle time alongside code review data to confirm the pattern held across different reviewers and repositories.
How to improve PR cycle time
- Reduce PR size. Set a team norm for maximum lines changed per PR, typically 200 to 400 lines. Smaller PRs are faster to review, easier to reason about, and less likely to sit idle because the cognitive load on the reviewer is lower. Watch your median PR size alongside cycle time as a leading indicator.
- Assign reviewers explicitly at PR creation. Unassigned PRs wait significantly longer than assigned ones. Build the habit into your PR template or automate it with a CODEOWNERS file. If you see high cycle time concentrated in specific repositories, reviewer assignment is often the first place to look.
- Set a review SLA and make it visible. A shared norm, such as first review within four hours during working hours, removes ambiguity. Post it in your team's working agreement. Use activity heatmap data to understand when your squad is most active and align review windows accordingly.
- Track review wait time separately from iteration time. If the bottleneck is the first response from a reviewer, that is a bandwidth or prioritization problem. If it is in iteration after feedback, that may point to unclear review comments or overly large change requests. DevStats surfaces the PR cycle time breakdown by stage, so you can direct the right intervention at the right stage.
- Connect PR cycle time to issue cycle time. A fast PR cycle time that still produces slow issue cycle time points to upstream bottlenecks in planning or scoping. Fixing review speed alone will not move the needle if issues are poorly defined before work begins.
PR cycle time vs. lead time for changes
PR cycle time and lead time for changes are related but measure different spans of your delivery process. Lead time for changes, one of the four core DORA metrics, measures the full journey from code commit to production deployment. PR cycle time is a subset of that journey, covering only the review and merge phase.
| PR cycle time | Lead time for changes | |
|---|---|---|
| Measures | Time in review and merge | Time from commit to production |
| Starts when | PR is opened | First commit is made |
| Ends when | PR is merged | Code reaches production |
| Best for | Diagnosing review bottlenecks | End-to-end delivery performance |
Use PR cycle time when you want to isolate the review process specifically. Use lead time for changes when you need to report on overall delivery performance to stakeholders or benchmark against DORA tiers.