DevieraDeviera
Free Tool

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.

PRs

From PR opened to the first substantive code review comment or approval.

hours

From first review to the PR being merged (including back-and-forth and CI wait).

hours

Number of engineers actively submitting PRs.

devs

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

What is a healthy PR cycle time? Industry benchmarks by team size

According to the 2024 DORA State of DevOps Report, elite teams review and merge pull requests in under 1 hour, high performers in under 1 day, medium performers in 1–3 days, and low performers take over 7 days. The benchmarks apply across team sizes — what differs is predictability and consistency, not the targets themselves.

PR cycle time & throughput: FAQ

What is PR cycle time?
PR cycle time is the total time from when a pull request is opened to when it is merged. It breaks into three phases: pickup time (how long the PR waits before a reviewer starts), review time (the active review and iteration period), and merge gap (time from approval to merge). Measuring the phases separately tells you which one is your bottleneck.
What is a good PR cycle time?
Elite engineering teams keep PR cycle time at or under 4 hours; high performers under 24 hours; teams above 72 hours are typically losing significant flow to review delays. The single biggest lever for most teams is pickup time — the wait before review even begins.
What is PR throughput?
PR throughput is the number of pull requests merged per week. It is the companion metric to cycle time: high throughput with low cycle time means the team is shipping continuously, while high throughput with high cycle time signals a review backlog — PRs opening faster than reviewers can clear them, inflating work in progress.
What is PR pickup time?
PR pickup time is the interval between a pull request being opened (or marked ready for review) and a reviewer starting their first review. It is usually the largest and most reducible slice of total cycle time, and the phase most sensitive to reviewer notifications and review-load balance.