Benchmarks in engineering are most useful when they're concrete enough to be actionable. "Improve your cycle time" isn't a benchmark. Knowing that your organization's 75th-percentile PR cycle time is 4.1 days while comparable organizations land around 1.8 days at the same percentile — that's a benchmark you can do something with.
This post aggregates data from 18 engineering organizations that consented to share anonymized metrics through Replixa's analytics pipeline. The organizations range from 120 to 680 engineers, all running primarily feature-development engineering teams rather than heavily infrastructure-weighted shops. The data covers calendar year 2024 into early 2025.
PR cycle time: where most organizations land
Cycle time here means time from PR open to merge — not to first review, not to approval, but to the final merge. This is the number that matters for DORA change lead time calculations.
Across our 18-org dataset:
- Median PR cycle time (all orgs): 18.4 hours
- 25th percentile (faster orgs): 9.1 hours
- 75th percentile (slower orgs): 38.7 hours
- 90th percentile: 84 hours
The spread between 25th and 75th percentile is almost 30 hours — roughly a 4x difference. That gap doesn't represent marginal execution differences; it reflects fundamentally different review process designs.
The fastest quartile of organizations share a cluster of characteristics: high automated pre-triage coverage (60%+ of PRs receiving automated first-pass review before human reviewer assignment), PR size discipline (median PR under 200 lines of diff), and low CODEOWNERS bottleneck (required-reviewer chains averaging fewer than 2 required approvals). The slowest quartile tend to have the opposite: minimal automation, large PRs, and 3–4 required reviewers as the default.
Reviewer-to-author ratios and load distribution
The healthy range for reviewer-to-author ratio at organizations in the 100–700 engineer range is roughly 1:3 to 1:5 — one engineer doing review work for every 3 to 5 engineers opening PRs. Below 1:5 and you're straining reviewer availability. Above 1:3 and reviewers are spending more than a third of their coding time in review context.
More important than the aggregate ratio is how review load is distributed within the org. In our dataset:
- The top 10% of reviewers (by review count) handled 54% of all review activity on average
- In the slowest-quartile organizations, the top 10% handled 71% of review activity
- In the fastest-quartile organizations, the top 10% handled 38% of review activity
Review load concentration is the single strongest predictor of slow cycle time in this dataset. More than PR size, more than team size, more than tooling selection. When review responsibility concentrates in a few people, those people become the bottleneck — and the bottleneck isn't a function of their individual capacity, it's a function of the system design.
First-pass approval rate
First-pass approval rate measures the percentage of PRs that receive an approval on the first human review visit, without requiring the author to make further changes. This is a quality signal as much as a throughput signal — a high first-pass rate suggests authors are consistently submitting well-prepared PRs, or that effective pre-submission checks are resolving routine issues before a human sees the diff.
Across our dataset:
- Median first-pass approval rate: 41%
- Fastest-quartile organizations: 58%
- Slowest-quartile organizations: 29%
Organizations with automated pre-triage showed first-pass approval rates clustering in the 55–65% range. When routine issues — style inconsistencies, convention deviations, missing error handling patterns — are resolved before human review, reviewers are more likely to approve on first pass. The remaining issues require architectural judgment, and reviewers either approve or open a meaningful discussion rather than cycling through style corrections.
Comment resolution rates
Comment resolution rate — the percentage of review comments that result in a code change before merge — is a proxy for review comment quality and actionability. A low resolution rate suggests either that comments are advisory rather than blocking, that they're ambiguous, or that authors are dismissing them.
In our dataset, the median comment resolution rate is 63% for human review comments. This varies considerably by commenter type:
- Senior engineer comments (Staff+): 74% resolution rate
- Mid-level engineer comments: 61% resolution rate
- Automated review as plain-text comments: 28% resolution rate
- Automated review as inline patch suggestions: 94% resolution rate
The gap between automated plain-text comments and inline patch suggestions is substantial and appears consistently across all 18 organizations. This isn't a content quality difference — it's a format difference. Inline patches with one-click apply collapse the task loop for the author, which is why resolution rates are so much higher.
Review coverage by PR type
Review coverage is harder to benchmark precisely because "substantive review" requires some judgment. A reasonable proxy: at least one comment per 100 lines of diff that triggers a response from the author.
Across our dataset, 68% of PRs met this threshold for substantive coverage. Interestingly, the fastest-quartile organizations don't have the highest per-PR coverage. They have lower per-PR depth but higher throughput. The slowest organizations sometimes show high coverage per PR because reviewers spend more time in each diff trying to be thorough.
This suggests a trade-off that engineering managers need to reason about explicitly: thoroughness per PR versus throughput. The organizations that have navigated this best use automation to cover the routine surface area (style, conventions, pattern consistency), allowing human reviewers to go deep on logic and architecture. Coverage becomes a function of automation for pattern/style, and human depth for correctness/intent.
Reading your own metrics against these benchmarks
We're not suggesting these numbers are targets everyone should hit — organizations with different risk profiles, different code ownership models, and different deployment cadences will have legitimately different optimal cycle times. A team deploying to production 10 times per day has different cycle time requirements than a team shipping monthly releases.
What the benchmarks are useful for: identifying which dimension of your review process is most out of line with comparable organizations. If your cycle time is above the 75th percentile and your review load concentration is above 70% in the top 10% of reviewers, those two data points together suggest a structural bottleneck problem rather than a tooling gap. Tooling changes won't fix a process where 4 people are required reviewers on 70% of all PRs.
If your first-pass approval rate is below 35% and your automated review comment resolution rate is below 40%, the tooling is running but not producing actionable output. That's a signal-to-noise problem in automation configuration — the system is posting too many low-confidence comments, and engineers have learned to filter them. Narrowing the automation scope to high-confidence suggestions typically recovers more than it loses in coverage.
Cycle time, review load distribution, and first-pass approval rate are the three metrics with the strongest correlations to overall engineering throughput in this dataset. If you're tracking PR metrics at all, those three should be in your regular EM review rather than sitting in a dashboard that nobody looks at.