A healthy number is one your team can review in a normal week, often a handful per repository. Set a limit on open update pull requests, group low risk updates together, and fast track security fixes separately. A queue that only grows teaches people to ignore every bot pull request.
Why queues grow
Update bots open a pull request for each outdated dependency. Reviewers see a long list of small changes and defer them. The list grows, versions drift, and the next jump is bigger and harder. Eventually nobody reads the list at all.
Use a work in progress limit
A work in progress limit caps how many items are open at once. Dependabot, for example, has an open pull requests limit for version updates, with a default of five, and security updates have a separate fixed limit of 10 that you cannot configure with that option. Setting it to zero pauses version updates for a package manager. Check the current documentation before relying on those numbers.
The effect is useful: once the cap is reached, no new version update pull requests appear until some are merged or closed. That turns an endless stream into a queue with a size.
Group the low risk updates
By default, Dependabot opens one pull request per dependency. Its groups option combines updates matching a rule into one pull request, and rules can filter by name patterns, dependency type and update type. A group for patch updates of development tools, for instance, replaces many small pull requests with one.
| Update type | Suggested handling |
|---|---|
| Security fix for reachable code | Fast track, separate pull request, review within the week |
| Patch updates to runtime dependencies | Group weekly, run tests, merge if green |
| Minor updates | Group monthly, review release notes |
| Major updates | Individual pull requests, planned work |
| Development tool updates | Group, lower priority |
Keep security separate
Do not let security updates wait behind routine updates. Give them their own path and label, a clear owner and a short target. Reachability and exploitation information helps decide which ones to rush.
Set a team budget
Agree on how much review time dependency updates get each week, for example one slot in the team routine. If the queue exceeds the budget for several weeks, tighten the grouping or raise the budget on purpose. Do not let it sit.
Measure the queue
Track the number of open update pull requests, the age of the oldest, and the share merged within two weeks. A rising oldest age is the earliest sign of trouble.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a ready fix is presented so the reviewer can act quickly.
Safeguard's autonomous remediation can open fix pull requests, and it is off by default with every category set to manual. The free scan shows which fixes are available.
Quick check
Should we turn off update bots to cut the noise?
Usually no. Cap and group them first. Turning them off lets versions drift, and security fixes become harder to apply.
Should a bot pull request be merged automatically?
Only for low risk updates with strong tests and a recorded policy. Keep human review for major changes and anything touching authentication or data.
Sources
Last reviewed: 19 October 2026.
