How Long Should a Pull Request Review Take? (2026 Data)

Direct answer

Two different clocks get called “review time”. The time a reviewer spends reading a diff is 15 to 60 minutes for a normal change. The time a pull request spends waiting for that reviewer is the real cost, and in the 2,189 merged public PRs we measured on 18 Oct 2026 the median wait to first review was 8.7 hours while the p90 was 212 hours. The median PR spent 52.7 percent of its entire open-to-merge life waiting. Fix the wait, not the reading.

How long should a pull request review take?

Direct answer: A reviewer should spend 15 to 60 minutes reading a normal pull request, and the PR should get a first response within 4 business hours and a decision within 24. Real repositories miss that badly. Across 2,189 merged public PRs measured 18 Oct 2026, p50 to first review was 8.7 hours and p90 was 212 hours.

The question hides two measurements that behave nothing alike.

Review effort is how long a human spends with the diff open. This is bounded by attention, not by process. The widely repeated guidance of roughly 400 lines per hour and no more than 60 minutes per sitting traces back to SmartBear’s study of around 2,500 reviews at Cisco, published in 2006. It gets quoted in almost every article on this topic without a date attached. It is a reasonable rule of thumb and a bad benchmark, because it describes one company’s practice twenty years ago.

Review latency is how long the pull request waits. This is a queueing property of your team, and it is where essentially all the recoverable time lives. It is also the number nobody publishes, which is why we went and measured it.

Here is what 2,189 merged pull requests from 12 well-known public repositories actually look like. Every figure is hours from PR open, harvested from the GitHub GraphQL API on 18 Oct 2026 over PRs created between 1 Apr and 31 Jul 2026. Bot authors and bot reviewers are excluded. Full method is in How we verified this.

Repository	n	% with a human review	To first review p50	To first review p90	To first approval p50	To merge p50	To merge p90	Median diff (lines)
microsoft/vscode	184	100.0%	1.2 h	25 h	2.0 h	3.3 h	70 h	168
nodejs/node	183	100.0%	5.3 h	157 h	6.2 h	167 h	664 h	28
grafana/grafana	187	100.0%	5.8 h	210 h	18 h	24 h	348 h	130
astral-sh/ruff	148	66.9%	8.4 h	139 h	9.8 h	5.9 h	143 h	84
apache/airflow	147	83.0%	9.9 h	233 h	17 h	22 h	925 h	77
vercel/next.js	191	97.9%	10 h	154 h	14 h	21 h	246 h	138
home-assistant/core	196	100.0%	10 h	114 h	26 h	52 h	211 h	62
rust-lang/rust	198	66.2%	12 h	213 h	28 h	42 h	595 h	74
django/django	200	99.5%	13 h	264 h	21 h	54 h	610 h	29
kubernetes/kubernetes	200	71.0%	15 h	868 h	37 h	112 h	1244 h	78
prometheus/prometheus	171	99.4%	17 h	162 h	19 h	24 h	530 h	33
pandas-dev/pandas	184	35.9%	40 h	497 h	50 h	50 h	479 h	55
All 12 pooled	2,189	85.2%	8.7 h	212 h	14 h	37 h	642 h	68

Three things jump out of that table.

The p50 is encouraging and the p90 is appalling. A median of 8.7 hours sounds like a team that is more or less functioning. A p90 of 212 hours means one PR in ten waits more than eight full days for anyone to look at it. Averages hide this completely, which is why almost every published “average review time” figure is useless. The distribution has a long tail and the tail is the problem.

Merge is fast once review starts. Pooled, the median gap from first review to merge was 6.7 hours, against a median of 8.7 hours from open to first review. Approval to merge was faster still, at a 1.1 hour median across the eight repositories that use GitHub approvals as the actual merge gate. The pull request is not slow. The queue in front of the pull request is slow.

The median PR spends more than half its life waiting for the first human. Across the 1,866 PRs that received a review, the median share of total open-to-merge time elapsed before the first review was 52.7 percent, and the mean was 51.9 percent. That is the single most actionable number in this dataset.

Pull request review turnaround time that keeps work moving

Direct answer: Target 4 business hours to first response and 24 hours to merge for normal changes. In our 2,189-PR sample, 41.3 percent of reviewed PRs hit the 4 hour mark and 65.1 percent hit 24 hours. Measure the p90, not the average: pooled p90 to first review was 212 hours, p95 was 482 hours.

Targets only mean something next to a distribution. Here is the pooled one.

Percentile	Open to first review	Open to first approval	Open to merge
p25	0.9 h	-	5.7 h
p50	8.7 h	14 h	37 h
p75	66 h	-	155 h
p90	212 h	319 h	642 h
p95	482 h	-	981 h
p99	1,300 h	-	-
Sample	n = 1,866	n = 1,724	n = 2,189

Restated as cumulative coverage, among the 1,866 PRs that received a human review:

First review arrived within	Share of reviewed PRs
1 hour	25.9%
4 hours	41.3%
8 hours	49.0%
24 hours	65.1%
48 hours	72.6%
72 hours	77.0%
7 days	88.8%

What I would hold a team to. A first substantive response inside 4 business hours, 80 percent of the time. A decision - approved, changes requested, or explicitly reassigned - inside 24 hours, 90 percent of the time. A p90 time-to-first-review under 24 hours. Those are harder than what 11 of our 12 repositories achieve, which is the point: open source carries structural disadvantages a company team does not have, so matching open source is not an achievement.

Why I set the bar on response rather than approval. An approval SLA is a bad instrument because the reviewer does not control whether the code is correct. Put a clock on approval and you get approvals. Put a clock on response and you get responses, which is the thing that was actually missing. Our deeper playbook on cutting review time goes into the mechanics.

Where to be deliberately slower. Changes to auth, payments, data migrations, or anything with a blast radius beyond one service deserve a longer clock and a second pair of eyes. That tradeoff is the subject of how many reviewers should approve a pull request, and the short version is that the extra approval costs you real latency, so spend it where it buys something.

Why do pull requests sit waiting for review?

Direct answer: Four causes, in order of how much time they cost: nobody is unambiguously on the hook, reviewer load has no cap, timezone spread turns one round trip into a day, and the diff is too big to start. Our data shows PRs over 1,000 lines waited a median 41 hours for a first review versus 4.4 hours for PRs under 50 lines.

Nobody is unambiguously on the hook

A PR assigned to a team is assigned to nobody. GitHub’s team-based review requests make this worse, not better, because the notification lands in nine inboxes and every one of them assumes someone else will take it. The fix is boring: a CODEOWNERS file with specific paths mapped to specific people, and require_code_owner_reviews enabled on the protected branch. GitHub’s own documentation describes that setting as blocking merging pull requests until code owners review them, which is exactly the forcing function you want.

Round-robin or load-balanced assignment within a team is the next step up. GitHub supports both algorithms on team review assignment. The load-balanced one is better in practice because round robin happily hands a fourth PR to someone who already has three.

Reviewer load has no WIP limit

Teams cap work in progress for authoring and never cap it for reviewing. A reviewer with eight open PRs assigned is not reviewing eight PRs; they are context switching across eight and finishing none. A hard cap of three open assigned reviews per person, with overflow automatically reassigned, does more for p90 latency than any tool purchase.

This is also the mechanism behind most review backlogs. Backlogs are not caused by too many PRs in aggregate; they are caused by a skewed assignment distribution where two people hold most of the queue. Look at the per-reviewer distribution before you conclude you need more reviewers.

Timezone spread turns one round trip into a day

If the author is in Berlin and the only code owner is in San Francisco, a single comment-and-response cycle costs 24 hours of wall clock and zero hours of effort. Two cycles cost two days. This is the single biggest driver of the long tail in distributed teams, and it is invisible in any metric that reports an average.

Two fixes work. Keep at least two code owners per path in different timezone bands. And make the first pass asynchronous and complete rather than incremental, so the author gets every objection at once rather than discovering them over three days.

The diff is too big to start

Large PRs do not just take longer to review, they take longer to begin reviewing, because reviewers triage by perceived cost and the intimidating ones get postponed. Our data shows that clearly.

Diff size (lines changed)	n	To first review p50	To first review p90	To merge p50	To merge p90
1 to 50	939	4.4 h	121 h	22 h	366 h
51 to 200	677	9.2 h	221 h	48 h	750 h
201 to 500	308	14 h	262 h	68 h	724 h
501 to 1,000	130	15 h	486 h	39 h	900 h
Over 1,000	135	41 h	502 h	99 h	930 h

Median time to first review rises roughly 9x from the smallest bucket to the largest. The p90 rises 4x. Note that the 501 to 1,000 bucket breaks the monotonic pattern on merge time - with n = 130 that bucket is noisy, and I report it rather than smoothing it away.

This is correlational. Large PRs are also disproportionately refactors, dependency bumps and cross-cutting changes, which are slower for reasons unrelated to size. But the direction is consistent across every bucket boundary and it matches what every team reports qualitatively. How big should a pull request be and pull request size best practices cover the sizing side properly.

The thing that is usually not the cause

Reviewer skill. Teams reach for training and review checklists when p90 latency is bad, and checklists address review quality, not review latency. If your p50 is 9 hours and your p90 is 200, you do not have a reviewing problem. You have a queueing problem wearing a reviewing problem’s clothes.

How quickly should reviewers respond to a pull request?

Direct answer: Within 4 business hours for a first response, treating acknowledge-and-schedule as a valid response. Only 41.3 percent of reviewed PRs in our 12-repo sample hit that. An AI reviewer posts in 2 to 10 minutes, which is why it compresses this phase even when its findings are mediocre.

The response does not have to be the review. Three responses are all acceptable inside the SLA:

1. A full review.
2. A comment saying when the review will happen, with a time.
3. An explicit decline and reassignment.

What is not acceptable is silence, because silence is indistinguishable from a lost notification and the author has no information to act on.

The honest case for AI review is latency, not catch rate. An AI reviewer posts its first pass within minutes of PR open. Anthropic’s documentation puts its Code Review at 6 to 10 minutes per review as of the 15 Oct 2026 GA, down from around 20 minutes in the research preview. CodeRabbit, Greptile and cubic all post in a similar window. Against a human p50 of 8.7 hours and a p90 of 212 hours, that is a two to three order of magnitude difference in time-to-first-signal.

That argument holds even if the AI’s findings are only okay, and the evidence says they are only okay. c-CRAB (arXiv 2603.23448) converted human review comments into executable tests across 184 PR instances from 67 repositories and 234 validated review comments. Its headline, quoted from the v2 text: “Taking the union across all four tools, 97 out of the 234 tests were passed by at least one tool (41.5%).” Per tool it was Claude Code 32.1 percent, Devin 24.8 percent, PR-Agent 23.1 percent, Codex 20.1 percent. Disclosure on that paper: five of its six authors are academic, but Ridwan Shariffdeen lists SonarSource as his affiliation, and the paper carries a disclaimer that its conclusions do not represent SonarSource policy. Sonar sells SonarQube and acquired Gitar in May 2026; Gitar is a paid sponsor of this site. SonarQube is not among the four tools c-CRAB evaluates, which blunts the conflict considerably, but we flag vendor-adjacent benchmarks everywhere else so we flag this one too.

Also worth knowing: the widely quoted “40 to 70 percent false positive rate” is not in the c-CRAB paper. No false positive rate is reported there for any reviewed tool. If you see that figure attributed to c-CRAB, the citation is wrong.

So: a tool that catches roughly a third of what a human catches, posted 100x sooner, is still worth having - because it moves the author’s first fix cycle from tomorrow to now. That is a weaker claim than the vendors make and a much more defensible one. Our review of what the benchmarks actually say goes through the rest of them.

The opposite effect is real too. An AI reviewer that posts 40 low-severity comments on every PR adds a triage step to the author’s critical path and makes latency worse. Severity ranking and a configurable minimum severity are not nice-to-haves, they are the difference between the tool helping and hurting. See AI code review tools with low false positives.

Pull request review process for faster releases

Direct answer: Five levers in order of effect on p90 latency: CODEOWNERS routing to named people, a 4-hour response SLA tracked as a p90, a WIP cap of 3 open reviews per reviewer, a merge queue to remove the post-approval rebase tax, and an AI reviewer running on PR open. Keep PRs under about 200 lines so all five work.

Lever	What it fixes	Typical setup cost	Where it shows up in the data
CODEOWNERS with named owners per path	Assignment ambiguity	One afternoon	Time to first review, p90 especially
Load-balanced team review assignment	Skewed reviewer queues	GitHub team setting	Time to first review p90
Response SLA of 4 business hours, tracked at p90	Silence	A Slack digest and a norm	Time to first review, all percentiles
WIP cap of 3 open assigned reviews	Reviewer context switching	A norm plus a dashboard	Time to first review p75 and p90
Merge queue	Serialised rebase after approval	Hours to days	Approval to merge
AI review on PR open	The first feedback cycle entirely	Minutes to hours	Time to first useful signal, not time to first human review
PR size discipline under 200 lines	All of the above, indirectly	Ongoing cultural work	Every metric in this article

A few notes on each.

CODEOWNERS is the highest-leverage change on this list and it is free. Named individuals, not teams, for anything you want reviewed quickly. Teams are fine for paths where latency does not matter.

A merge queue fixes a phase this article has mostly ignored, because in our data it is small. Pooled, approval to merge had a 1.1 hour median across the eight repositories where GitHub approvals are the real gate. But that median hides the case merge queues exist for: a busy trunk where every approved PR has to rebase against a main branch that moved while CI ran. If your approval-to-merge p90 is in the tens of hours and your CI is slow, that is the signal. What is a merge queue covers the mechanics.

AI review on PR open, not on request. A tool you have to summon is a tool that adds a step. Every major option supports automatic review on PR open: CodeRabbit, Greptile, cubic, Qodo, GitHub Copilot and Anthropic Code Review. Set the depth tier down, not up, for the default path. Anthropic exposes Quick, Standard and Deep per repository, set by an organisation Owner; Standard is the default and Quick is the right setting for a low-risk service.

Do not buy a tool to fix a routing problem. If your p90 is 200 hours because two people own every path, an AI reviewer will post helpful comments into the same void. Fix routing first, then measure again, then buy.

What about DORA?

DORA gets cited constantly in this conversation and it does not measure review latency. dora.dev defines change lead time as “the amount of time it takes for a change to go from committed to version control to deployed in production” (verified at source 18 Oct 2026). That window starts before the pull request exists and ends long after the merge. It bundles review latency together with CI duration, release cadence and deployment mechanics, which means it cannot tell you whether review is your bottleneck.

The performance-band thresholds that get quoted alongside it - elite, high, medium, low - are not on that page, and we did not verify the current band definitions against the primary Accelerate State of DevOps report. Treat any specific DORA band figure you see in a blog post, including the ones in our own DORA explainer, as directional until you have checked it against the report for the year in question.

The practical point: if you want to know whether review is slowing you down, measure review directly. Open to first review, open to first approval, open to merge, reported as p50 and p90. Three numbers, and every one of them is in the GitHub API.

How we verified this

The original dataset. On 18 October 2026 we queried the GitHub GraphQL API for pull requests in 12 well-known public repositories, filtered to is:pr is:merged created:2026-04-01..2026-07-31, taking up to 200 per repository ordered by creation date descending. The creation window closes 2.5 months before the measurement date so that slow PRs had time to merge.

For each PR we recorded createdAt, mergedAt, every review in the reviews connection (first 60) and every issue comment in the comments connection (first 30), each with author login and __typename.

Exclusions. We dropped PRs authored by bots, identified by GraphQL __typename == "Bot", a [bot] login suffix, or membership in an explicit list of accounts that are bots registered as Users. The explicit list was built by inspecting the accounts producing sub-minute first responses and includes rustbot, rust-log-analyzer, rust-timer, nodejs-github-bot, k8s-ci-robot, k8s-triage-robot, meeseeksmachine, bors and the usual CI and AI-reviewer accounts. We also excluded reviews and comments authored by the PR author, and by any bot. That left 2,189 human-authored merged pull requests.

Definitions. Time to first review is hours from createdAt to the earliest submittedAt across reviews by a non-author human, in any state. Time to first approval uses only APPROVED reviews. Time to merge is createdAt to mergedAt. Percentiles are linear-interpolated on the sorted sample.

Spot check. We verified the pipeline against the GitHub REST API for individual PRs. Example: django/django#21712 was created 2026-07-31T20:51:14Z, approved by smithdc1 at 2026-08-01T13:47:27Z and merged 2026-08-02T21:50:42Z, which our pipeline recorded as 16.9 hours to approval and 49.0 hours to merge. Both match.

What we could not do and what is wrong with this data.

• facebook/react returned zero results from GitHub’s search index for merged pull requests, with and without a date filter, on 18 Oct 2026. We could not determine why and substituted vercel/next.js, prometheus/prometheus and astral-sh/ruff. The 12 repositories are not a random sample of anything; they are well-known projects we chose.
• Only merged PRs are in the sample. PRs that were opened and abandoned, or are still open, are excluded. This biases every latency figure downward, because the slowest pull requests are the ones that never merge. The real numbers for your team, if you count everything, will be worse than these.
• kubernetes/kubernetes approval figures understate reality. Only 26.0 percent of its merged PRs carried a GitHub approving review, because Kubernetes gates merges through Prow using /lgtm and /approve comments and labels rather than GitHub’s review approval. We confirmed this by inspecting kubernetes/kubernetes#141086, where jpbetz posted /approve and /lgtm as a comment on 2026-09-09 with no GitHub review approval recorded. The same caveat applies in weaker form to rust-lang/rust, which merges through bors.
• Low review coverage in some repos is self-merging, not missing data. pandas-dev/pandas shows 35.9 percent of merged PRs with a human review and astral-sh/ruff shows 66.9 percent. In both, core maintainers merge their own changes without a recorded review. Across all 12 repos, 14.8 percent of merged PRs had no human review record and 8.7 percent had neither a review nor a human comment.
• Open source is not your company. Volunteer reviewers, no shared working hours and no management escalation path all make open source latency worse than a well-run company team’s. Use these as a reference distribution and a method, not as a target.
• Review connection truncation. We fetched the first 60 reviews and first 30 comments per PR. A PR with more than that would be truncated, but truncation affects the tail of a thread and all our metrics use the earliest entry, so the effect is nil.
• No business-hours correction. All durations are wall clock. A PR opened at 6pm Friday carries weekend hours in its latency. We judged a business-hours model too assumption-heavy to be honest across 12 projects with contributors in every timezone.

Other claims verified at source on 18 Oct 2026. Anthropic’s Code Review documentation at code.claude.com/docs/en/code-review states “A review never approves or blocks the pull request, so the decision to merge stays with your team”, and that REVIEW.md is read from the base or default branch and never from the pull request’s own changes. GitHub’s branch protection documentation describes require_code_owner_reviews as blocking merging pull requests until code owners review them. DORA’s change lead time definition is quoted above from dora.dev.

What we did not verify. The DORA performance band thresholds. The SmartBear/Cisco 400-lines-per-hour and 60-minute figures, which we cite as a dated rule of thumb from a 2006 study rather than as a current measurement. Any vendor’s claimed review-time improvement percentage, none of which we were able to trace to a published methodology.

Recommendations

Criteria: effect on p90 time-to-first-review, cost to implement, and whether the evidence for it is ours, independent, or a vendor’s.

If you measure nothing else, measure three numbers. Open to first review, open to first approval, open to merge, each as p50 and p90. Pull them from the GitHub API with the same method we used. Do it before you buy anything. If your p90 to first review is under 24 hours, review is not your bottleneck and you should go look at CI.

First move: CODEOWNERS with named individuals, and require_code_owner_reviews on. Free, takes an afternoon, and addresses the largest single cause of the long tail. Put at least two owners per path in different timezone bands.

Second move: a response SLA of 4 business hours, tracked at p90, visible in Slack. A daily digest of PRs past SLA, oldest first. Do not make it an approval SLA.

Third move: cap open assigned reviews at 3 per person. The backlog is almost always distribution, not volume.

Buy an AI reviewer for the latency, and configure it for signal. Run it on PR open, set a minimum severity so it stays off the author’s critical path, and start on the cheapest depth tier. CodeRabbit at 24 dollars per dev per month annual on the Essentials tier is the most common choice, though note it now covers only 1 linked repository on that tier - the cap is 5 on Team, 10 on Advanced. cubic is free for 20 PR reviews per GitHub organisation per month and is the cheapest way to run the experiment. Anthropic Code Review requires a Claude Team or Enterprise plan and will never approve or block, which matters if you were hoping it could satisfy a required-approval rule. It cannot.

Do not expect an AI reviewer to replace the human pass. On the best independent evidence available, the union of four agentic tools passed 41.5 percent of executable tests derived from real human review comments, with the best single tool at 32.1 percent. That is a useful first pass and nothing like a substitute. AI code review vs manual review sets out where the line actually falls.

Then fix PR size, because it makes everything else work. Our own data shows a 9x spread in median time-to-first-review between PRs under 50 lines and PRs over 1,000. See how big should a pull request be and pull request review best practices for the rest of the playbook, and how many reviewers should approve a pull request for the decision about when a second approval is worth the wait.