Taming Dependabot: A 2026 Guide to Grouping, Cooldowns, and Cutting PR Noise

Taming Dependabot A 2026 Guide to Grouping Cooldowns and Cutting PR Noise
Back to blog
The Default Behavior Is Still Noisy
Grouping Dependabot Updates

1. Group by Semantic Versioning
2. Group by Dependency Type
3. Group by Package Pattern
4. New in 2026: Grouping Across Directories and Ecosystems Cooldowns: Don't Adopt a Package the Minute It Ships Scheduling: Set a Predictable Cadence Putting It Together Other Dependabot Changes Worth Knowing About in 2026 When Routine Maintenance Becomes a Security Emergency A Practical Checklist Further reading Taming Dependabot: A 2026 Guide to Grouping, Cooldowns, and Cutting PR Noise For engineering teams, keeping dependencies current is a constant balancing act. Automated updates are essential for defending the software supply chain, but a steady stream of one-PR-per-package bumps can bury a team in review work. GitHub itself has put numbers on this: an analysis of Microsoft's GCToolkit repository found that roughly one in six of its commits — 92 out of 578 — were routine Dependabot version bumps, with 61 of them landing in a single recent 12-month stretch. That's a lot of review and CI cycles spent on maintenance rather than features.

The good news is that Dependabot has grown well past "one PR per dependency." Between grouped updates, package cooldowns, and a default cooldown GitHub rolled out in mid-2026, it's now possible to get a predictable, low-noise update cadence without giving up security coverage. Here's what actually works, and what changed most recently.

The Default Behavior Is Still Noisy
Out of the box, enabling Dependabot version updates still means one pull request per outdated dependency. Twenty outdated packages means twenty PRs, each triggering CI, each needing review, and each capable of creating a merge conflict for the other nineteen once one of them lands. That one-to-one mapping between dependency and PR is the root of "PR fatigue" — and it's exactly what grouping and scheduling are designed to fix.

Grouping Dependabot Updates
Grouped updates let you define rules in dependabot.yml that bundle multiple dependency bumps into a single pull request instead of one each. GitHub supports a few different ways to group, and they can be combined.

1. Group by Semantic Versioning Major version bumps are the ones most likely to introduce breaking changes; minor and patch releases are usually safe to batch together.

Copy
version: 2
updates:

• package-ecosystem: "npm" directory: "/" schedule: interval: "weekly" groups: safe-updates: applies-to: version-updates update-types: - "minor" - "patch" With this in place, if fifteen packages release patch or minor updates in the same week, Dependabot opens one PR containing all of them — major updates still arrive individually so they get proper scrutiny.

1. Group by Dependency Type Production and development dependencies (test frameworks, linters, type stubs) carry very different risk profiles, since dev dependencies never ship to production.

Copy
groups:
production-dependencies:
dependency-type: "production"
development-dependencies:
dependency-type: "development"

1. Group by Package Pattern Related packages — an SDK family, a framework and its plugins — often need to move in lockstep. Pattern-based groups keep them together and prevent version mismatches.

Copy
groups:
aws-sdk:
patterns:
- "@aws-sdk/"
angular-framework:
patterns:
- "@angular/"
update-types:
- "minor"
- "patch"
Groups are evaluated in the order they're defined, and a dependency is only ever placed in the first group it matches — worth knowing if your rules overlap.

1. New in 2026: Grouping Across Directories and Ecosystems Two newer capabilities extend grouping beyond a single ecosystem in a single folder:

Cross-directory grouping (February 2026): In monorepos, the same dependency pinned in a dozen services used to trigger a dozen nearly identical PRs when it was bumped. Dependabot can now consolidate an update to the same dependency across multiple directories into one pull request.
multi-ecosystem-groups: A newer top-level key lets you group updates that span different ecosystems in the same repository — for example, bundling a Docker base-image bump with a related Terraform provider update into a single PR when they're tied to the same piece of infrastructure.
Security updates can be grouped too, separately from version updates, using applies-to: security-updates — useful when a single ecosystem has several vulnerable packages patched at once.

Cooldowns: Don't Adopt a Package the Minute It Ships
Grouping controls volume; cooldowns control when an update is even considered. The concern is timing-based supply-chain attacks: a compromised package version gets published, and an automated tool that checks for updates immediately can open a PR against it before the community has had a chance to flag and pull it.

GitHub's own reasoning, explained by product manager Carlin Cherry, points to a real incident in which several widely used packages — collectively downloaded more than 2 billion times a week — were briefly replaced with compromised versions. They were caught and removed within about two hours, but that window was long enough for an automated update tool to see the new release, open a PR, and put it in front of a developer.

Timeline:

The cooldown option went generally available on July 1, 2025, covering every supported ecosystem except NuGet at launch; NuGet and Helm support followed on July 29, 2025.
On July 14, 2026, GitHub made a three-day cooldown the default for Dependabot version updates across every ecosystem on github.com, with no configuration required. It's rolling out to GitHub Enterprise Server as of version 3.23.
The cooldown applies only to version updates. Security updates are never delayed — when a vulnerability is disclosed, Dependabot still opens a fix PR immediately.
You're not locked into the three-day default. The cooldown block supports finer control:

Copy
version: 2
updates:

• package-ecosystem: "npm" directory: "/" schedule: interval: "daily" cooldown: default-days: 5 semver-major-days: 30 semver-minor-days: 7 semver-patch-days: 3 include: - "*" exclude: - "your-time-sensitive-package" default-days is the fallback delay for any update that doesn't match a more specific rule, and it's the only option supported across all ecosystems. semver-major-days / semver-minor-days / semver-patch-days let you set a longer wait for major bumps than for patches (only available for SemVer-aware ecosystems). include / exclude scope the cooldown to specific packages, support wildcards, and allow up to 150 entries each; exclude always wins over include. Days must be between 1 and 90. Setting default-days: 0 effectively opts a repository back out of any delay. One subtlety worth knowing: cooldown is a floor, not a rolling freeze. If you set default-days: 14 on a weekly schedule, Dependabot opens a PR for the newest version that's been out for at least 14 days — it won't wait indefinitely just because something even newer shipped yesterday.

Scheduling: Set a Predictable Cadence
The other lever is simply how often Dependabot checks at all. Daily checks make sense for security-sensitive ecosystems, but for routine version updates, weekly or monthly is usually plenty:

Copy
schedule:
interval: "weekly"
day: "monday"
Many teams schedule this for Monday mornings so grouped PRs are ready as part of the week's kickoff rather than trickling in at random.

Putting It Together
Combining grouping, cooldown, and a weekly schedule turns a daily drip of single-dependency PRs into one predictable, reviewable batch:

Copy
version: 2
updates:

• package-ecosystem: "npm" directory: "/" schedule: interval: "weekly" day: "monday" cooldown: default-days: 3 semver-major-days: 14 groups: production-dependencies: applies-to: version-updates dependency-type: "production" update-types: - "minor" - "patch" development-dependencies: applies-to: version-updates dependency-type: "development" Other Dependabot Changes Worth Knowing About in 2026 A few smaller updates have landed alongside grouping and cooldowns:

Alert assignment: Dependabot alerts can now be assigned directly to a collaborator, team, or AI agent, giving each vulnerability a clear owner without a separate tracking tool.
Delegated alert dismissal: Organizations can require a reviewer's approval before a Dependabot alert can be dismissed.
Dependabot CLI and MCP toolset: Update jobs can be tested locally with the open-source Dependabot CLI, and a Dependabot toolset is now exposed through the GitHub MCP Server in public preview, so agents and external tools can query Dependabot data.
Faster failure detection: Dependabot now pauses a repository's scheduled jobs after 15 consecutive failures, down from 30, so misconfigurations surface sooner.
Audit logging: Changes to dependabot.yml and related settings now generate audit log events at the organization level.
When Routine Maintenance Becomes a Security Emergency
Grouping and cooldowns solve the everyday noise problem, but a large-scale disclosure — a Log4j-style event — is a different situation: Dependabot Security Updates can start firing across dozens of repositories at once, cooldown-exempt and all.

GitHub's own answer for this is Security Campaigns, a feature of GitHub Advanced Security. Campaigns let a security team target a specific class of alert — a CVE, a vulnerability category — across every affected repository, optionally auto-create tracking issues per repo, and monitor remediation progress from a central dashboard, with Copilot Autofix able to suggest fixes for large batches of alerts at once. As of the most recent GitHub changelog updates, campaigns cover code scanning and secret scanning alerts, while Dependabot alerts get their own cross-repository prioritization and assignment tools inside Security Overview.

Some teams layer a dedicated third-party tool on top of GitHub's native alerting for SLA tracking and audit evidence. InstaSLA, for example, is a smaller SaaS product built specifically around GitHub security alerts: it groups related alerts into "fix campaigns," assigns severity-based remediation deadlines, escalates work that's at risk of breaching SLA, and exports the resulting ownership and completion history for compliance purposes. It's one option among several — plenty of teams instead route Dependabot alerts into an existing Jira or incident-management workflow rather than adopting a GitHub-specific tool. Which approach makes sense depends mostly on whether you need audit-ready SLA evidence or just want the alerts triaged inside tools you already use.

A Practical Checklist
Move routine version-update schedules from daily to weekly or monthly.
Group minor/patch updates by SemVer level, dependency type, or related package family.
Keep the default three-day cooldown unless you have a specific reason to shorten or disable it — remember it doesn't touch security updates.
For monorepos, take advantage of cross-directory grouping so one dependency bump doesn't fan out into a dozen near-duplicate PRs.
Assign owners to Dependabot alerts (natively, or through a dedicated SLA tool) so a large-scale disclosure has a clear response path instead of just a pile of new PRs.
Reducing Dependabot noise isn't about turning automation down — it's about controlling when and how updates arrive, so the team actually reads and merges them, and so the one PR that really is urgent doesn't get lost in a pile of routine ones.

Further reading
GitHub Blog — Tame Dependabot: Group your updates, slow the cadence, keep security fast
GitHub Changelog — Dependabot version updates introduce default package cooldown
GitHub Docs — Dependabot options reference
GitHub Docs — Optimizing the creation of pull requests for Dependabot version updates
GitHub Blog — Found means fixed: Reduce security debt at scale with GitHub security campaigns
InfoQ — GitHub Introduces Default "Cooldown" Policy for Dependabot Version Updates