How Many Reviewers Should Approve a Pull Request? (2026)

Direct answer

One competent, independent reviewer for most pull requests. Two when the blast radius, the security surface or a specific regulatory scope justifies the extra wait. In the 2,189 merged public PRs we measured on 18 Oct 2026, 59.2 percent merged with exactly one distinct human approver and only 14.5 percent with two. The second approval is usually a compliance artifact rather than a quality mechanism, and SOC 2 separation of duties is satisfied by one independent approver, not two.

How many reviewers should approve a pull request?

Direct answer: One, for the large majority of changes. Require a second only where the change can take down a system, touches a security boundary, or sits inside a named regulatory scope. Across 2,189 merged public PRs measured 18 Oct 2026, the mean number of distinct human approvers was 1.08 and 59.2 percent had exactly one.

We pulled the approver count for every human-authored merged pull request in 12 well-known public repositories. Here is the distribution.

Repository	n	Mean distinct approvers	0 approvers	1 approver	2 approvers	3+ approvers
vercel/next.js	191	1.03	2.1%	92.7%	5.2%	0.0%
grafana/grafana	187	1.11	0.5%	88.8%	10.2%	0.5%
home-assistant/core	196	1.20	0.5%	80.6%	17.9%	1.0%
prometheus/prometheus	171	1.26	0.6%	75.4%	21.1%	2.9%
microsoft/vscode	184	1.32	0.0%	71.7%	25.0%	3.3%
django/django	200	1.36	1.5%	67.5%	26.0%	5.0%
astral-sh/ruff	148	0.68	35.1%	62.2%	2.7%	0.0%
apache/airflow	147	1.12	17.0%	60.5%	18.4%	4.1%
rust-lang/rust	198	0.49	53.0%	44.9%	2.0%	0.0%
pandas-dev/pandas	184	0.36	67.9%	28.3%	3.8%	0.0%
kubernetes/kubernetes	200	0.28	74.0%	23.5%	2.5%	0.0%
nodejs/node	183	2.78	0.0%	15.8%	39.3%	44.8%
All 12 pooled	2,189	1.08	21.2%	59.2%	14.5%	5.1%

Read that table carefully, because two rows are measurement artifacts rather than policy.

kubernetes/kubernetes shows 74 percent zero approvers and that is wrong in spirit. Kubernetes gates merges through Prow, where maintainers type /lgtm and /approve as comments and the bot applies labels. Those are real approvals; they just are not GitHub review approvals, so the API does not see them. We confirmed this on kubernetes/kubernetes#141086, where jpbetz posted /approve and /lgtm as a plain comment on 2026-09-09 with no review approval recorded. rust-lang/rust has a weaker version of the same issue via bors, and the high zero-approver rates in pandas-dev/pandas and astral-sh/ruff are core maintainers merging their own work.

nodejs/node is the outlier that proves the point. It is the only project in the sample where two approvals is the norm, with 44.8 percent of merged PRs carrying three or more. It also had the second-slowest median time to merge in the whole dataset at 167 hours, against a 5.3 hour median to first review. Node is not slow at reviewing. It is slow at accumulating the required number of approvals.

Strip out the four projects that do not use GitHub approvals as the merge gate and you are left with 1,459 pull requests across eight repositories, and the picture is clean: one approver is the normal case, two is the exception, and the exception is slower.

Distinct human approvers	n	Merge p50	Merge p90	Median diff (lines)
1	1,015	22 h	356 h	72
2	297	70 h	672 h	64
3 or more	112	95 h	426 h	-

That is correlational and I am not going to pretend otherwise. Harder, riskier changes attract more reviewers, so some of the latency gap is the change, not the policy. Two controls make the point more honest. First, median diff size is almost identical between the one-approver and two-approver groups, at 72 versus 64 lines, so it is not simply that bigger PRs get more approvals. Second, excluding nodejs/node - which requires two approvals by policy and therefore drags the two-approver group toward its own slow baseline - the gap narrows at the median but widens at the tail: 21 versus 27 hours at p50 on n = 986 and n = 225, and 312 versus 682 hours at p90.

The cleanest causal-ish number is the gap between the two approvals themselves. Across the 409 PRs in the core eight that got at least two distinct approvers, the median wait from the first approval to the second was 6.2 hours, rising to 50 hours at p75 and 150 hours at p90. Excluding node it is 3.2 hours at p50 and 166 hours at p90. That interval is pure waiting. Nothing is being produced in it.

For contrast, the median time from first approval to merge across the same eight repositories was 1.1 hours. Once the approval requirement is satisfied, PRs land almost immediately. The approval requirement is the gate, and every additional unit of it is a gate you pay for in wall clock.

How many reviewers should a pull request have?

Direct answer: One assigned reviewer, selected by path ownership. Reviewers and approvers are different counts: our 12-repo sample averaged 1.31 distinct human reviewers but only 1.08 distinct approvers, so people routinely comment without approving. Assign one; let others opt in.

There is a difference between how many people should look at a PR and how many must sign it off, and conflating them produces bad policy.

Approvers should be the minimum that satisfies risk and compliance. That is almost always one.

Reviewers should be whoever can usefully contribute, and that number should not be mandated. In our pooled data the mean distinct human reviewer count was 1.31 against 1.08 approvers, which is the signature of a healthy pattern: people drop into PRs they care about, leave a comment, and do not block the merge.

The practical rule I would write into a handbook:

• Assign exactly one reviewer, chosen by CODEOWNERS path match, never by team-wide request. A PR assigned to a team is assigned to nobody.
• Add a second only if the decision table below says so, and name the specific person, not the team.
• Make it trivially easy for anyone else to comment without being on the hook. Post the PR in a channel; do not request their review.

Here is the decision table. It is keyed on the four variables that actually change the answer.

Signal	One approver	Two approvers	Notes
Blast radius	Single service, reversible, behind a flag	Shared library, schema migration, anything deployed to all tenants at once	Reversibility matters more than size. A 900-line change behind a flag is safer than a 9-line migration
Security surface	No change to authn, authz, crypto, secrets handling, or input parsing at a trust boundary	Any of those	Make this a CODEOWNERS path, not a judgement call
Regulatory scope	Outside the named audit scope	Inside PCI DSS cardholder data environment, or a change your SOC 2 scope statement specifically covers	SOC 2 itself does not require two. Some scoping documents and some PCI requirements effectively do. Read yours
Author seniority and context	Author has shipped in this area before	First contribution to the codebase, first change in this directory, or a contractor or external contributor	This is the one case where two approvals genuinely buys knowledge transfer rather than just assurance
Change type	Feature work, bug fix, test, docs, dependency bump with a passing test suite	Infrastructure as code, CI pipeline configuration, anything that can self-grant privileges	A CI config change can exfiltrate secrets. Treat it like production
Reversibility	One-command revert	Data loss on revert, or an irreversible external side effect	Payment capture, email send, external API writes

If more than about 15 percent of your pull requests are landing in the right-hand column, the problem is not your approval policy. It is that too much of your codebase is high blast radius, and that is an architecture conversation.

Should every pull request need two approvals?

Direct answer: No. The second approval is usually a compliance artifact, not a quality mechanism, and SOC 2 separation of duties is satisfied by one independent approver. Blanket two-approval rules produce rubber-stamping plus a measurable wait - a 6.2 hour median gap between first and second approval in our data, 150 hours at p90.

This is the section most articles get wrong, so let me be precise about what the compliance requirement actually is.

SOC 2 change management is Common Criteria CC8.1. What auditors test is that changes to production systems were authorised, designed, tested, approved and documented before they shipped, and that the approval came from someone other than the person who made the change. That last part is separation of duties.

One independent approver satisfies separation of duties. Two does not satisfy it any harder. There is no counting rule in the Trust Services Criteria, and I want to be explicit about the limits of that claim: the AICPA Trust Services Criteria is a paid download and we could not retrieve the verbatim CC8.1 text from a free public source on 18 Oct 2026, so we are not quoting it. What we are confident stating is the negative - no public summary of SOC 2, and no auditor guidance we could find, specifies a number of approvers. If someone tells you SOC 2 requires two, ask them for the clause.

What auditors genuinely care about, and what teams genuinely miss:

1. The approver is not the author. Both platforms default to this. GitLab’s documentation states that merge request authors do not count as eligible approvers on their own merge requests by default, though a project setting can turn that protection off. GitHub does not permit self-approval.
2. The approval survives the last commit. This is the one teams get wrong. Without protection, an author can get an approval, push three more commits, and merge. GitHub’s branch protection API exposes require_last_push_approval, described in its documentation as “whether the most recent push must be approved by someone other than the person who pushed it.” That setting, not the approval count, is what makes separation of duties hold in practice.
3. Stale approvals are dismissed. GitHub’s protected branches documentation describes an option to “dismiss stale pull request approvals when commits are pushed that affect the diff in the pull request.” Turn it on.
4. The trail is retained. PR history, review state, timestamps, and who merged. GitHub and GitLab both retain this by default. Do not delete repositories inside your audit window.

Those four settings give you a defensible change management control. The count of approvals is not one of them.

What a blanket two-approval rule actually produces:

• Rubber-stamping. The second reviewer knows a competent person already reviewed it. Their marginal value is low and they know it, so the second approval converges on a glance. This is the mechanism; I am not aware of a published measurement of it on commercial teams, and if you know of one I would genuinely like to see it.
• A real wait. Measured: a 6.2 hour median and a 150 hour p90 between first and second approval in the core eight repositories, on n = 409.
• A diffusion of responsibility. Two named approvers often means neither one owns the outcome.
• A reviewer load problem. Two approvals per PR is exactly double the review assignments, and review load is the thing driving the long tail of pull request review latency.

Where two approvals is the right call anyway: a named regulatory scope that your own scoping document requires it for, changes to the approval machinery itself, and teams where the second approval is explicitly a training mechanism for a new engineer. In the last case, say so out loud - it is a mentoring policy, not a quality gate, and it should expire.

For the deeper treatment of what regulated teams actually need to configure, see AI code review for regulated teams. This article stays on the approval count.

Can review automation assign reviewers based on code ownership?

Direct answer: Yes, natively, on every major platform. GitHub uses CODEOWNERS plus require_code_owner_reviews, which its docs describe as blocking merging pull requests until code owners review them. GitHub team assignment adds round robin or load balance routing. GitLab offers Code Owner approval rules on Premium and Ultimate.

The routing layer is platform-native and free. You do not need to buy anything for this.

Mechanism	Platform	What it does	Verified detail (18 Oct 2026)
CODEOWNERS + require_code_owner_reviews	GitHub	Blocks merge until the matched owner approves	GitHub docs: “Blocks merging pull requests until code owners review them.” Any PR affecting code with a code owner must be approved by that code owner
required_approving_review_count	GitHub	Sets the approval count per protected branch or ruleset	API docs: “Use a number between 1 and 6 or 0 to not require reviewers.” Minimum 0, maximum 6
require_last_push_approval	GitHub	Forces the final push to be approved by someone else	API docs: “Whether the most recent push must be approved by someone other than the person who pushed it.”
Team code review assignment, round robin	GitHub	”chooses reviewers based on who’s received the least recent review request, focusing on alternating between all members of the team”	Supports skipping named members and including child teams
Team code review assignment, load balance	GitHub	”chooses reviewers based on each member’s total number of recent review requests and considers the number of outstanding reviews for each member”	This is the one you want. Round robin ignores existing queue depth
Code Owner approval rules	GitLab	Path-scoped required approvals	Premium and Ultimate tiers. Owner must hold Developer, Maintainer or Owner role. Max required approvals is 100
Prevent merge request creator approval	GitLab	Separation of duties	On by default: authors do not count as eligible approvers on their own MRs
Graphite automations	Third party	Rule-based reviewer addition	Docs: “Add reviewers to the PR. This supports both individuals and GitHub teams.” No documented CODEOWNERS integration or load balancing

Load balance over round robin, every time. Round robin picks whoever was asked least recently, which cheerfully hands a fourth concurrent review to someone already holding three. Load balance considers outstanding reviews. That difference is the whole WIP-limit argument, implemented as a dropdown.

Two owners per path, in different timezone bands. A single code owner is a single point of failure that converts to a 24 hour round trip the moment they go on holiday. This is the most common reason a CODEOWNERS rollout makes p90 latency worse instead of better.

Do not put a * catch-all at the top of CODEOWNERS. GitHub matches the last matching pattern, so a global rule at the top is harmless, but a global rule at the bottom overrides every specific rule above it. Order matters and it bites people.

GitLab teams: Code Owner approval rules are Premium and above. If you are on GitLab Free, your ownership routing is advisory only. That is a real budget consideration and most comparison articles omit it.

AI code review tools that assign findings to code owners

Direct answer: We could not verify this capability in any AI reviewer’s documentation on 18 Oct 2026. The tools scope reviews by path, not findings by owner. CodeRabbit documents path instructions and path filters using glob patterns with no CODEOWNERS reference. Owner routing is done by the host platform, not the reviewer.

This is one of those prompts where the honest answer is a gap, so here is the gap.

What AI reviewers actually offer is path-scoped review behaviour, which is a different thing.

Tool	Path-level control documented	Routes findings to a CODEOWNERS owner	Can satisfy a required approval
CodeRabbit	Yes. Path instructions, described as “custom review instructions for specific file paths using glob patterns”, plus path filters controlling which files are included or excluded	Not documented	No. Posts review comments
Anthropic Code Review	Yes, via REVIEW.md and CLAUDE.md, read from the base or default branch and never from the PR’s own changes	Not documented	No, by design. Docs: “A review never approves or blocks the pull request, so the decision to merge stays with your team”
GitHub Copilot code review	Yes, via custom instructions and automatic review rules	Not documented	Yes, if an admin enables it. Default is a Comment review that does not count toward required approvals. Approvals are off by default and configurable at enterprise, organisation and repository level
Greptile	Yes	Not documented	No
Qodo	Yes	Not documented	No
Graphite	Automations match on file patterns and add reviewers	Adds reviewers by rule, but no documented CODEOWNERS read	Graphite adds humans; the humans approve
Gitar	Fixes rather than comments: fix, commit, run CI, commit only on green	Not documented	No. Sponsor of this site, and it has no published third-party benchmark - the same caveat we apply to everyone

The one tool that can satisfy a required approval is GitHub Copilot, and I would not turn it on. The capability is real and documented: when approvals are enabled, Copilot can submit an approving review that satisfies the repository’s required-approval rule the same way a teammate’s approval would, and the approval is dismissed if new commits are pushed. But if that approval is the evidence behind your SOC 2 separation of duties control, you have replaced an independent person with a model, and no auditor is going to accept that as a second human. Enable it only on paths where the approval requirement exists for flow-control reasons rather than assurance reasons, if such paths exist for you. Mostly they do not.

Anthropic’s position is the clearer one. It will not approve or block under any configuration. That is a design decision, not a missing feature, and it means Code Review cannot become a bottleneck or a false sense of sign-off. Note the other constraints: Team and Enterprise plans only, GitHub only, and it is unavailable to organisations with Zero Data Retention or the HIPAA configuration applied, and not covered under Anthropic’s BAA. The configuration that makes Claude Code eligible for PHI work is the configuration that disables Code Review.

What to build instead, if you want owner-aware findings. Combine the two layers. Use CODEOWNERS with require_code_owner_reviews so the right human is blocked on the PR, and use the AI reviewer’s path instructions so the findings on that path are tuned to what the owner cares about. CodeRabbit path instructions, Anthropic REVIEW.md, and Copilot custom instructions all let you write different review rules per glob. That gets you most of the value of owner-aware findings without a product that does not exist.

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, up to 200 per repository ordered by creation date descending. The 2.5 month gap between the end of the window and the measurement date gives slow PRs time to merge.

For each PR we recorded createdAt, mergedAt, and every review in the reviews connection with author login, __typename and state. An approver is a distinct non-bot, non-author login with at least one APPROVED review; where the same person approved twice we kept the earliest timestamp.

Exclusions. Bot-authored PRs were dropped, identified by GraphQL __typename == "Bot", a [bot] login suffix, or an explicit list of bot accounts registered as Users, built by inspecting accounts producing sub-minute responses: 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. Reviews by the PR author and by bots were excluded from all counts. Final sample: 2,189 human-authored merged pull requests.

The core eight. For the latency-versus-approver-count analysis we excluded kubernetes/kubernetes, rust-lang/rust, pandas-dev/pandas and astral-sh/ruff, because in those projects a GitHub approving review is not the merge gate. That leaves 1,459 PRs across eight repositories: vercel/next.js, prometheus/prometheus, microsoft/vscode, nodejs/node, apache/airflow, grafana/grafana, home-assistant/core and django/django.

Spot check. Verified against the REST API on individual PRs. django/django#21712 was created 2026-07-31T20:51:14Z and approved by smithdc1 at 2026-08-01T13:47:27Z, which our pipeline recorded correctly as one distinct approver at 16.9 hours.

What is wrong with this data.

• Only merged PRs. Abandoned and still-open PRs are excluded, which biases latency figures downward and may bias approver counts in either direction.
• The approver-count-versus-latency comparison is correlational. Riskier changes attract more approvers. We controlled crudely by reporting median diff size per group (72 lines at one approver versus 64 at two, so size is not the explanation) and by reporting the comparison with and without nodejs/node. We did not control for change type, author tenure, or repository, and you should not read a causal claim into it.
• Prow and bors invisibility. Described above. The zero-approver rates in four repositories are a measurement artifact of those merge systems, not evidence that changes merged unreviewed.
• Open source is not your company. Treat these as a reference distribution and a reproducible method.
• The 12 repositories are not a random sample. We chose well-known projects. facebook/react returned zero results from GitHub’s search index for merged pull requests on 18 Oct 2026, with and without a date filter, and we could not determine why; we substituted vercel/next.js, prometheus/prometheus and astral-sh/ruff.

Documentation verified at source on 18 Oct 2026. GitHub branch protection REST API for required_approving_review_count (minimum 0, maximum 6), require_last_push_approval and require_code_owner_reviews. GitHub team code review assignment for the round robin and load balance definitions. GitHub Copilot code review documentation for the default Comment review, the off-by-default approval setting and its enterprise, organisation and repository scopes. Anthropic Code Review documentation at code.claude.com/docs/en/code-review for the never-approves-or-blocks statement, the REVIEW.md base branch rule, and the ZDR, HIPAA, CMEK and BAA exclusions. GitLab merge request approval rules for the 100 approval maximum, the Code Owner role requirement and the default author-cannot-approve behaviour. CodeRabbit review instructions documentation for path instructions and path filters. Graphite automations documentation for rule-based reviewer addition.

What we could not verify.

• The verbatim text of SOC 2 Common Criteria CC8.1. The AICPA Trust Services Criteria is a paid download. We state the negative claim - no number of approvers is specified - rather than quoting the criterion.
• Whether any AI code review tool routes findings to CODEOWNERS owners. We found no product documentation describing it. Absence of documentation is not proof of absence of the feature; if a vendor ships it, we will update this page.
• Any published measurement of rubber-stamping under two-approval policies on commercial teams. The mechanism is widely described and, as far as we can find, never measured.
• CodeRabbit, Greptile, Qodo and Gitar approval behaviour was taken from product documentation and our existing tool pages rather than tested live on a repository for this article.

Recommendations

Criteria: satisfies separation of duties, minimises added latency, and is configurable rather than cultural.

Default to one required approving review. Set required_approving_review_count to 1. This is the observed norm even in large open source projects: 59.2 percent of merged PRs in our sample had exactly one distinct human approver, and the mean was 1.08.

Turn on the three settings that actually matter more than the count. require_last_push_approval, dismissal of stale approvals on new commits, and require_code_owner_reviews. Those three give an auditor a defensible change management control. The approval count does not.

Route with CODEOWNERS naming individuals, two per path, in different timezone bands. Then set GitHub team review assignment to load balance rather than round robin, because load balance is the only one that looks at outstanding review queue depth.

Escalate to two approvals by path, never by repository. Auth, payments, migrations, CI configuration, infrastructure as code, and anything in a named audit scope. Use a dedicated ruleset so the policy is legible from the config rather than from a handbook. Expect to pay for it: a 6.2 hour median and 150 hour p90 wait for the second approval, measured.

Do not let an AI reviewer be the required independent approver. Anthropic Code Review refuses to approve by design. GitHub Copilot can approve if an admin enables it, and that setting is off by default for good reason. If the approval is your compliance evidence, it needs to be a person.

Do add an AI reviewer as a non-blocking first pass. It compresses the waiting phase, which is the real bottleneck - see how long a pull request review should take for the latency data behind that claim. Keep PRs small so one reviewer can actually do the job: how big should a pull request be and pull request size best practices. And if approved PRs are queueing behind rebases rather than behind reviewers, the fix is a merge queue, not another approver.

Further reading on this site: pull request review best practices for the full process playbook, AI code review for regulated teams for the compliance detail this article deliberately skips, DORA metrics explained for why change lead time will not tell you whether your approval policy is the problem, and the best AI code review tools for the tool landscape.