PR Cycle Time Benchmark Tool
See where your pull request velocity sits against DORA Elite, High, Medium, and Low performers. Pinpoint whether your bottleneck is review lag, post-review delays, or PR size — and get a clear fix.
Your PR Metrics
Use last month's numbers for the most accurate result.
Total pull requests merged across all repos your team owns.
From PR opened to the first substantive code review comment or approval.
From first review to the PR being merged (including back-and-forth and CI wait).
Number of engineers actively submitting PRs.
Enter your metrics and click Benchmark to see your result.
How the benchmark is calculated
Review lag (40%)
Time from PR open to first meaningful review. The biggest driver of cycle time loss — Elite teams review within 2 hours.
Merge gap (40%)
Time from first review to merge. Includes CI wait, re-review, and approval latency. Equally weighted with review lag.
PR volume (20%)
PRs per developer per month. Very low or very high throughput signals either low activity or oversized PRs — both carry risk.
Tier thresholds are derived from the DORA State of DevOps report (Elite / High / Medium / Low performer definitions) and corroborated by LinearB's engineering benchmark dataset. View the full benchmark data →
Understanding PR cycle time and pull request throughput
PR cycle time measures the total time from when a pull request is opened to when it is merged. It captures the full pull request cycle time across three phases: pickup time (how long a PR waits before a reviewer picks it up), review time (the active review and iteration period), and merge gap (time from approval to actual merge). Each phase can hide a different bottleneck in your development process.
PR throughput is a companion metric: the number of pull requests merged per week. High throughput with low cycle time means your team is shipping continuously. High throughput with high cycle time can indicate a review request backlog — many PRs opening faster than reviewers can clear them, inflating work in progress.
Common factors that inflate PR cycle time in software development teams:
- Long pickup time: Reviewers aren't getting notified promptly or are overloaded with review requests
- Draft PRs left open: Draft PRs sitting in the queue inflate cycle time averages without being actionable
- High work in progress: Too many open PRs per engineer fragments attention and slows review and deploy cadence
- Code quality issues: PRs with large diffs or missing test coverage attract more review rounds
- Review process friction: Unclear ownership, missing CODEOWNERS, or slow CI blocking the review and deploy flow
Use this calculator to identify which phase of your cycle time measures is the bottleneck, then track improvement week over week as you address it.
Monitor your PR cycle time automatically
Deviera watches every PR across your repos and alerts your team the moment cycle time degrades — routing structured tickets to Linear, Jira, or ClickUp before delays compound.
Start free — no credit card