Size the limit to your reviewer time, not to the number of outdated packages. Dependabot allows five open version update pull requests by default, with a separate limit of 10 for security updates. For a small project, two or three at a time is often more honest.
The defaults, from the documentation
GitHub's options reference says Dependabot allows five open version update pull requests at once, and raises no more until some are merged or closed. Security update pull requests have a separate fixed limit of 10 that you cannot configure with that option. Setting open-pull-requests-limit to zero turns version updates off for a package manager, which is useful as a pause switch.
Renovate documents a prConcurrentLimit that defaults to 10, and an hourly limit on creating pull requests. Its documentation also warns that the hourly limit only restricts creation, so Renovate can still rebase existing branches, which triggers more CI runs. To limit CI load strictly it recommends commitHourlyLimit, which also limits automatic rebasing.
Three costs to count
| Cost | What drives it |
|---|---|
| Your attention | Each pull request needs a decision |
| CI minutes | Every open and rebased pull request runs your pipeline |
| Merge conflicts | Several updates touching one lockfile collide |
A pull request that sits open for weeks is a hidden cost: it conflicts, gets rebased, and runs CI again each time.
Ways to cut the volume without ignoring updates
- Group. Combine related updates by pattern, dependency type or update type. Dependabot processes a dependency into the first group that matches.
- Slow the schedule. Weekly or monthly intervals both exist, along with quarterly and cron.
- Split by type. Group development tool updates into one pull request and keep runtime dependencies separate, so the risky ones get individual attention.
- Ignore deliberately. The
ignoreoption takes dependency names, version ranges or update types such as major. Use it for packages you cannot upgrade yet, and leave a comment saying why and when to revisit.
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "monthly"
open-pull-requests-limit: 3
ignore:
- dependency-name: "django"
update-types: ["version-update:semver-major"]
A way to pick the number
Count how many pull requests you reviewed carefully last month. If it was four, a limit of three leaves room for security updates, which sit outside the configurable limit. If you cannot remember, start with three.
Raise the limit when the queue is empty before the next scheduled run for a few cycles in a row. Lower it when you find yourself closing pull requests unread.
What not to do
Do not set the limit so low that security updates stop. Those use their own limit, but a paused version update does not pause alerts. And do not turn on auto-merge to make the queue vanish unless your tests really protect you.
Try it yourself
Click through it at your own pace, or open it full screen. See how a fix can be ready while your review capacity, not the tool, is the bottleneck.
Quick check
Does lowering the limit hide security updates?
Not through that option. Security update pull requests have their own limit of 10, and alerts are separate.
Why is my CI so busy with a low limit?
Rebasing existing pull requests also triggers CI. Check your bot's rebase settings and the number of open branches.
Safeguard fix pull requests are off by default and every category starts on Manual, so volume stays in your hands. Start with the free scan.
Sources
- GitHub docs, Dependabot options reference: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference
- Renovate docs, configuration options: https://docs.renovatebot.com/configuration-options/
Last reviewed: 19 October 2026.
