Set the cap near what your team can review in a day, usually between three and ten across a repository. GitHub's dependency update bot defaults to five open version update pull requests, and pauses new ones until some are merged or closed. A cap turns a flood into a queue.
Why a cap helps
A backlog of 60 bot pull requests teaches people to ignore all of them. A cap keeps the visible list short and puts the most useful items in front of reviewers. It also reduces merge conflicts between open fixes that touch the same lockfile.
GitHub's options reference documents the default of five for version updates and notes that security update pull requests have a separate fixed limit of 10 that the option does not change. Treat these as examples of reasonable orders of magnitude, not rules for your team.
Choosing your number
Start with a simple calculation:
- Count how many bot pull requests your reviewers actually close in a typical week.
- Divide by the number of working days.
- Set the open cap to about two days of that throughput.
A team that handles ten a week should start near four. Raise it only after the open list stays short for a month.
What to do with the overflow
Capping does not make findings disappear. Keep the full list somewhere reviewers can see it:
| Overflow handling | Good for |
|---|---|
| Queue in the tool, order by exploitability and reachability | Most teams |
| Ticket per repository with a count | Teams that track in a tracker |
| Weekly digest | Low risk repos |
Ordering matters more than the cap itself. A reachable, actively exploited vulnerability should leave the queue before a cosmetic upgrade. See prioritising with reachability.
Watch the signals
If PRs sit open for weeks, lower the cap or fix the review process. If they merge within a day and the queue is always empty, raise it. The fix PR quality metrics post covers the numbers to track.
Per repository or across the organisation
Caps usually apply per repository, which is the right grain for review. But a team that owns twelve repositories still faces twelve queues. Add a team level view so the owner sees the total, and consider a lower per repository cap for teams that own many. During a pilot, start low and raise it deliberately, so you learn the review rate rather than assuming it.
Where Safeguard fits
Safeguard's reachability analysis helps put exploitable issues first, and autonomous remediation opens fix pull requests with every category on Manual by default. A free scan shows how many findings you would be queueing.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how many findings drop out of the urgent list once reachability is considered.
Quick check
Does a cap delay urgent security fixes?
Not if urgent items are ordered first or have their own path. Check that your cap does not block them.
What is a sign the cap is too high?
Pull requests older than two weeks with no review comments.
Sources
Last reviewed: 19 October 2026.
