Start with limits, not rules. Cap how many pull requests the tool may open per hour and at one time, enable it on a single repository first, and let the first backlog drain over a week or two. Tighten grouping and schedules only after you see real pull requests.
Why the first run is the worst
An old repository may be many versions behind on dozens of packages. The first scan finds all of it at once. The documentation of one update bot describes the pattern: it opens an onboarding pull request, you merge it, it may open a pin dependencies pull request, and then it creates every upgrade pull request needed. That can overwhelm continuous integration, because branches are rebased and retested each time you merge one.
Defaults differ between tools, which is useful to know before you compare them. Per the docs we read, that bot limits itself to two new pull requests per hour and ten concurrent ones by default, while another major bot's default is five open version update pull requests. Both can be changed.
A rollout plan
- Pick one repository with good tests and an owner who will pay attention. Do not start with the most critical service.
- Set a low hourly creation rate and a small open cap, such as three, before you merge the onboarding change.
- Decide what happens to major updates now. Holding them for manual approval is a common choice for the first month.
- Let the first batch run. Merge what is safe, close or ignore with a written reason what is not.
- Review after a week. Count merged, closed, and left open. Our post on why developers ignore bot pull requests explains what a poor ratio means.
- Add grouping and schedules, then widen to the next repository.
What to limit and why
| Control | What it protects |
|---|---|
| Pull requests per hour | CI capacity and notification volume |
| Open pull requests at a time | Reviewer attention and branch conflicts |
| Approval for major updates | Surprise breaking changes |
| Staged repositories | The ability to learn before scaling |
Security fixes are different
Do not let a throttle delay an advisory fix. Both bots we looked at treat security pull requests separately. One documents a separate, fixed limit of ten open security update pull requests that the version update cap does not control. The other says it always creates security pull requests even when the concurrent limit is reached. Check what your own tool does, because a low cap on version updates can otherwise starve urgent work.
A note on pinning
Some tools offer to pin every dependency to an exact version as their first act. That is a legitimate hardening step, but it is also a large change that touches many files and triggers many rebases. Decide whether you want it before you accept it, and do it separately from your first upgrade cycle.
Quick check
Is it better to merge everything in the first week?
No. A burst of merges means a burst of rebases and test runs, and untested bulk upgrades make failures hard to trace. Merge in small, tested batches.
Should I set the open cap to zero to stop the flood?
Be careful. In some tools zero removes the limit. Read the documentation for your tool and set a small positive number instead.
Safeguard can help you decide what to merge first. It builds an SBOM from your manifests and lockfiles, and reachability analysis shows which flagged dependencies your code actually calls. Autonomous fix pull requests are off by default, with every category on Manual. You can try a free scan.
Sources
- Update bot documentation: configuration options, hourly and concurrent limits
- Code host documentation: update bot options reference, open pull request limits
Last reviewed: 19 October 2026.
