GitHub Capped Open Pull Requests. The Stale Queue Is Still Invisible.
On 6 August 2026 GitHub let organizations cap how many open PRs a user without write access can have at once. That throttles intake. It does not show which open PRs have already gone idle.
By Ahmad Hajjar
On 6 August 2026, GitHub added organization-level controls for pull request limits.
Organizations can now centrally configure how many open pull requests a user without write access may have at one time. When a contributor reaches the limit, they must close or merge an existing pull request before opening another.
The feature addresses a real problem: too much incoming contribution volume competing for finite maintainer attention.
But it solves intake, not triage.
A pull request limit can reduce how quickly new work enters the queue. It does not tell you which pull requests already in that queue have stopped moving.
GitHub is controlling intake
GitHub first introduced repository-level pull request limits on 17 June 2026. The August update lets organizations manage those limits centrally instead of configuring repositories individually.
The motivation is straightforward.
GitHub describes maintainers dealing with increasing contribution volume, including repeated low-quality and drive-by pull requests. The limit gives maintainers a way to constrain how much work any one contributor without write access can keep open.
For some projects, that already makes a meaningful difference.
Nicholas Tindle of AutoGPT told the GitHub Blog:
“It’s helped us want to review pull requests again.”
That is exactly what an intake control should do: reduce noise before more of it reaches the review queue.
There is, however, another question once the queue already exists:
Which open pull requests still have active review attention, and which have quietly stopped moving?
A creation limit does not answer that.
It also does not apply to developers who already have write access. If the review queue is growing because your own engineering organization is producing work faster than it can review and integrate it, contributor limits will not change that dynamic.
A cap is not a filter. Intake and triage are different jobs.
Measure what has gone quiet
One useful way to inspect the existing queue is idle share.
GitQuick treats an open pull request as idle when it has had no review activity for at least 72 hours at the end of an analysis run.
Review timestamps are used as the activity signal. Pull request discussion comments are not counted, so idle share should be interpreted specifically as review inactivity, not as proof that nobody has interacted with the pull request at all.
The calculation is simple:
Idle share = idle open PRs ÷ all open PRs in scope
Consider two organizations with 100 open pull requests.
If one has five PRs without review activity for three days and the other has 70, those queues require very different kinds of attention even though their total open-PR count is identical.
That is why queue size and queue hygiene need to be measured separately.
Opened-versus-merged tells you whether backlog pressure is growing.
Idle share asks a different question:
Of the work already open, how much is no longer receiving review attention?
This matters more as code production accelerates
The distinction is becoming more important as AI changes the economics of producing code.
A 2026 study covering more than 100,000 GitHub developers found that successive generations of AI coding tools produced much larger gains at the coding stage than at the final delivery stage.
With autocomplete, synchronous agents and asynchronous agents combined, commit activity increased by roughly 180%, while shipped releases increased by about 30%.
The authors describe the effect as a production bottleneck: improvements become progressively smaller as work moves from writing code toward reviewing, integrating, testing and releasing it.
That does not mean every additional commit becomes a pull request, or that AI-generated code necessarily causes an idle queue.
It does mean that organizations increasingly need to understand what happens after code is produced.
When upstream production becomes cheaper, downstream attention becomes easier to saturate.
That makes review latency, backlog pressure and idle work more useful signals than raw coding activity alone.
What five public GitHub organizations show
GitQuick's public showcase provides a useful illustration.
The following data comes from one-month analysis windows completed between 21 and 27 August 2026. The organizations are public open-source projects, so these figures should not be treated as benchmarks for private product-engineering teams.
They are useful as examples of how differently open queues can behave.
| Organization | Open PRs | Idle PRs | Idle share | Median idle |
|---|---|---|---|---|
| React | 235 | 198 | 84.3% | 16.8d |
| Vercel | 1,384 | 1,121 | 81.0% | 12.1d |
| Google Cloud | 1,278 | 897 | 70.2% | 13.0d |
| Microsoft | 8,585 | 5,858 | 68.2% | 7.7d |
| Uber | 71 | 38 | 53.5% | 4.4d |
These five are intentionally not simply the highest idle-share organizations in the showcase.
They represent very different queue sizes.
Uber had only 71 open pull requests in its analysis window. Microsoft had 8,585. Vercel and Google Cloud both had more than 1,000.
Yet review inactivity is visible across all of them.
That is the useful observation — not that one organization is “better” or “worse” than another.
The interesting questions are:
- How large is the inactive part of the queue?
- How old is it?
- Is that share increasing or decreasing?
- Does the same pattern persist across repeated analysis runs?
- Is the problem concentrated in particular repositories or branches?
Those questions are much more actionable than the open-PR count on its own.
Google Cloud: 897 pull requests without review activity for 72 hours
Google Cloud is a useful concrete example.
In the showcase window ending 27 August 2026, GitQuick counted 1,278 open pull requests.
Of those, 897 — 70.2% — had no review activity for at least 72 hours.
Median time since the last human review across the open set was 13 days.
That does not mean all 897 pull requests should be merged.
Some may need to be closed.
Some may be waiting on the author.
Some may belong in draft.
Some may simply need a reviewer to look again.
That is precisely why this is a triage signal, not a productivity score.
The first useful action is not “review 897 pull requests.”
It is to identify the oldest and most relevant idle work, then decide what should happen to it.
A pull request limit may prevent additional external contributions from accumulating as quickly.
It still would not identify those 897 existing pull requests.
What to do with an idle queue
If a significant portion of your open PRs has stopped receiving review activity, there are four useful things to do.
1. Start with the oldest work
Do not treat every idle PR equally.
Inspect the oldest items first and decide whether they still represent active work.
The correct action may be to request review, assign an owner, return the PR to draft, or close it.
2. Separate intake problems from review-capacity problems
External contribution volume and internal engineering throughput are different systems.
GitHub's pull request limits specifically target contributors without write access.
If your own developers are producing the idle work, look instead at reviewer capacity, ownership, branch strategy, merge queues and the distribution of review work.
3. Look at backlog pressure alongside idle share
A large idle share does not necessarily mean the queue is growing.
Likewise, a growing queue does not tell you whether the work inside it is active.
Track both.
If more PRs are opening than merging, you have a backlog imbalance.
If a large portion of the existing queue has stopped receiving review activity, you have a triage problem.
They often occur together, but they are not the same signal.
4. Watch whether the problem persists
One analysis run is a snapshot.
A release event, contributor spike or end-of-sprint surge can temporarily distort the queue.
The more useful question is whether the same condition appears repeatedly.
GitQuick compares completed analysis runs and distinguishes signals that are new, worsening or persistent.
If idle work remains high across several runs, the answer is probably not a one-time cleanup. It is a review-process problem worth addressing systematically.
Different review problems need different signals
Idle pull requests are only one failure mode in a review pipeline.
A PR that waits days for its first review suggests reviewer availability or ownership problems.
A PR that receives approval quickly but then waits before merge points elsewhere — potentially toward CI, merge queues, release processes or branch strategy.
A queue where more work opens than closes indicates backlog pressure.
An idle queue indicates something different:
work entered the system, but review attention stopped.
That distinction matters because each problem requires a different response.
The goal should not be to optimize one dashboard number.
It should be to identify where work stops flowing and respond to the actual bottleneck.
GitQuick groups these checks in its Signals playbook.
For deeper context:
- Pull request review latency: how to measure it and find bottlenecks
- Your PRs Are Approved. Why Aren't They Merging?
- More PRs open than close: your review queue is growing
See the queue before connecting your own organization
You can inspect public GitHub organizations in GitQuick without installing anything or signing up.
Start with:
Open an organization, go to Signals, and inspect the Idle Pull Request signal.
Then compare it with your own organization.
GitHub can now help control how quickly certain new pull requests enter the queue.
You still need to know what happened to the work already sitting inside it.
Analyze your GitHub organization →
Disclaimer: This analysis uses public GitHub metadata and GitHub's published changelog. Showcase figures come from one-month analysis windows completed between 21 and 27 August 2026 and will change as the underlying data refreshes. GitQuick defines an idle pull request as an open PR with no review activity for at least 72 hours. Review timestamps are used as the activity proxy; pull request comments are not counted. Time-in-queue measurements are bounded by the analysis window. GitQuick cannot determine whether a showcased organization has enabled GitHub's pull request limits. Public open-source organizations are not representative benchmarks for private engineering teams. GitQuick is not affiliated with or endorsed by GitHub or any organization mentioned in this article.