Pick a cap your reviewers can clear in one week, and start low. Documented defaults from two common bots are 5 and 10 open pull requests. If the queue is always full, the cap is too high or review capacity is too low. If it is always empty, you can raise it.
What the documented defaults are
One hosted bot documents a default of 5 open version-update pull requests, with no new ones until some are merged or closed. Setting the value to zero temporarily disables version updates for that package manager. Security update pull requests have their own fixed limit of 10 that you cannot configure.
Another bot caps open pull requests at 10 by default. It also offers an hourly limit on new pull requests, and notes that it may still rebase existing branches, which triggers CI. A separate commit hourly limit restricts rebases too, giving tighter control of CI load.
Why a cap helps
- Reviewers see a queue they can finish, so pull requests do not rot.
- CI load stays predictable. Rebases on many open branches can flood runners.
- Merge conflicts drop. Many open branches touching the same lockfile conflict with each other.
Why a cap can hurt
A cap can starve important updates. If five low-value pull requests sit open, a needed update waits behind them. Security updates having a separate limit exists for this reason. Check that your tool does something similar, or that urgent updates bypass the queue.
Sizing guide
| Situation | Starting cap |
|---|---|
| One small service, two reviewers | 3 to 5 |
| Monorepo with many packages | Group first, then 5 to 10 |
| Backlog of hundreds of stale updates | Low cap plus a planned catch-up sprint |
| Library with many contributors | 5 and watch conflicts |
Steps
- Measure how many dependency pull requests your team reviews per week today.
- Set the cap to roughly that number.
- Review the queue weekly. If more than half the open pull requests are older than two weeks, lower the cap or add grouping.
- Handle a large backlog separately. Do not raise the cap to chew through it, because all those pull requests will conflict. Close the oldest and let the bot recreate the current ones.
- Keep a separate path for security fixes so they never wait behind routine updates.
Watch the right signal
The number of open pull requests is a symptom. The better measure is how long the oldest one has waited. If your median age is climbing, you are accumulating update debt regardless of the cap.
Quick check
What happens when the cap is reached?
The bot stops opening new pull requests until some are merged or closed. For one documented bot, security updates use a separate limit.
Can I pause updates for a while?
Yes. Setting the open pull request limit to zero temporarily disables version updates for that package manager in one documented bot.
Safeguard scans manifests and lockfiles into an SBOM, uses reachability analysis to show which flagged dependencies your code actually calls, and can open fix pull requests (off by default, every category on Manual). You can try a free scan on a public repository.
Sources
Last reviewed: 19 October 2026.
