Keep Dependabot useful across many client repos by grouping routine updates into fewer pull requests, setting a sensible schedule and open pull request limit, using a cooldown for fresh releases, and keeping security updates separate. Standardize one configuration template, then adjust per client risk.
The problem with defaults
An agency with thirty client repositories can receive a hundred update pull requests a week. People stop reading them, and the one that matters sits unmerged. The fix is not turning the tool off. It is shaping what it opens.
Settings that matter
All of these come from GitHub's Dependabot options reference.
Groups. Groups bundle updates into fewer, targeted pull requests. If a dependency matches more than one rule it joins the first group it matches, and anything matching no rule still gets its own pull request. A common split is one group for dev tooling and one for production minor and patch updates.
Schedule interval. This controls how often Dependabot checks for version updates, from daily to yearly, or by cron. Weekly suits most client work.
Open pull requests limit. By default, once five version update pull requests are open, no more are raised until some are merged or closed. Security update pull requests have a separate limit that cannot be changed with this setting. Setting it to zero pauses version updates for that package manager.
Cooldown. It delays version updates by a number of days. The documentation says a default cooldown of 3 days applies to version updates even if you do not set one, and that it does not apply to security updates. A short wait gives the community time to spot a bad release.
Directories. Use the directories key with globbing for monorepos. Grouping across directories has limits, such as requiring the same ecosystem.
A starting template
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
open-pull-requests-limit: 5
groups:
dev-tools:
dependency-type: "development"
prod-minor-patch:
dependency-type: "production"
update-types: ["minor", "patch"]
Copy it into each repository, then tune. Major version bumps stay as separate pull requests, which is where you want human attention.
Who merges what
Decide in the maintenance agreement. Low risk groups can merge on green tests. Major bumps and anything touching authentication or payments get a human. For clients on a retainer, put the cadence in writing, such as a weekly review.
Measure it
Track open update pull requests per repository and their age. If a repo has ten stale pull requests, the configuration is too noisy or nobody owns it. Both are fixable.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the monitoring view and watch how new findings arrive over time. Compare that with the weekly rhythm above.
Quick check
Are security updates affected by the schedule?
Security update pull requests have their own limit and are not delayed by the version update cooldown, per the options reference. Check current behavior in GitHub's docs.
Should every client repo share one configuration?
Share a template, not a rigid file. Higher risk clients may want daily checks and tighter review.
Sources
Last reviewed: 19 October 2026.
