Skip to content
SRE & DevOpsDeep Dive Published Updated 6 min readViews unavailable

Dependabot Groups and Cooldowns: Keep Security Updates on a Separate Track

Configure Dependabot update groups and cooldowns without delaying security fixes, and keep grouped dependency changes reviewable in CI.

Dependabot can reduce update noise by combining compatible changes into fewer pull requests. That convenience is safe only when routine version updates and vulnerability remediation remain separate policy decisions. In dependabot.yml, update groups can be scoped to version-updates or security-updates; a cooldown delays version updates, but does not apply to security updates. Treating those controls as one generic batching switch can obscure whether a vulnerable dependency is waiting for a release window or whether routine upgrades are simply being grouped for review.

This guide uses the current Dependabot configuration contract documented by GitHub. It focuses on grouping and cooldown boundaries, not on whether a particular alert is exploitable or whether an upgrade is compatible with your application.

There are two update paths to reason about

Version updates are configured per package ecosystem and directory. Their schedule tells Dependabot when to look for newer versions. Group rules can combine matching updates into one pull request, and the update-types filter can limit a version group to major, minor, or patch releases. GitHub documents a default three-day cooldown for version updates even if no cooldown block is present; a repository can set specific day counts or include and exclude dependencies. Security updates are driven by vulnerability alerts and have a separate enablement path. The version-update cooldown does not postpone them.

Grouping also has a policy boundary. A group without applies-to defaults to version updates. A security group must say applies-to: security-updates. Rules are processed in file order, and a matching update goes into the first group it matches. Each ecosystem configuration has its own group set unless you deliberately use a supported multi-ecosystem feature; do not assume an npm rule also applies to GitHub Actions or another package manager. For groups, the optional dependency-type filter accepts development or production only for the documented ecosystems: Bundler, Composer, Mix, Maven, npm, and pip. group-by: dependency-name is specifically for version updates, not security updates. A matching exclude-patterns entry keeps a dependency out of a group even when an include pattern matches it.

Make routine batching explicit

The following example groups only routine npm patch and minor version updates. Major routine version updates remain separate pull requests; the distinct security group can combine eligible npm security fixes of any SemVer level because it has no update-types filter. Four cooldown days is an example policy choice, not a GitHub requirement:

version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    groups:
      routine-patch-and-minor:
        applies-to: version-updates
        patterns:
          - "*"
        update-types:
          - patch
          - minor
      security-fixes:
        applies-to: security-updates
        patterns:
          - "*"
    cooldown:
      default-days: 4

The configuration is scoped to the manifest location at /. In a monorepo, define the actual package directories deliberately. Copying this block to another ecosystem requires a separate updates entry and a check that the ecosystem supports the options you use. Keep the package manager’s lockfile committed and have CI install from that lockfile; the Dependabot YAML determines proposal behavior, not whether the resulting dependency graph is safe to ship.

Cooldown inclusion is not the same as update filtering. The cooldown.include and cooldown.exclude lists decide which version updates wait; a dependency excluded from cooldown is eligible at the next configured Dependabot run, and an exclusion takes precedence if a name appears in both lists. That is different from an ignore rule, which can prevent matching versions from being proposed. Use an exclusion when the intent is “do not wait for this package,” not “never update this package.” Keep the naming and review policy explicit so a maintainer does not mistake a faster update for a suppressed one.

The broad wildcard under security-fixes is intentionally easy to read but may produce a large, coupled remediation pull request. If a repository needs more review isolation, divide security groups by package family, dependency type where supported, SemVer update type, or another documented criterion. Ensure the group identifiers meet the documented syntax and put narrower rules before broader rules when an update could match more than one group. A rule-order mistake can change the pull-request grouping without changing the packages that Dependabot considers.

Avoid turning a group into a blind merge unit

A grouped pull request is a review and CI boundary, not proof that every change is compatible. A group of unrelated packages can fail for one package’s breaking behavior, and merging the group expands the combined change surface. For routine updates, use a grouping size your test suite can diagnose. Separate high-risk runtime, framework, or infrastructure-tool upgrades when they need independent rollout or rollback plans. For security groups, balance faster coordinated remediation against the difficulty of attributing a regression to one member.

Do not use cooldown as an informal vulnerability grace period. GitHub explicitly limits it to version updates. Grouped security updates require the dependency graph, Dependabot alerts, and Dependabot security updates to be enabled. If a security update is absent, inspect those prerequisites, whether the alert exists, whether the manifest directory is configured correctly, and whether the dependency can be updated. A missing pull request is not evidence that the vulnerability is irrelevant. Conversely, a security pull request is not an automatic authorization to merge: review the alert, release notes, lockfile diff, tests, and any application-specific migration requirement.

Verify behavior with a small repository fixture

Before rolling a policy across many ecosystems, use a test repository or a controlled branch with a few representative direct and transitive dependencies. Confirm that a patch and minor version update enter the intended group and a major update stays separate. To verify the security-update path, use a disposable repository or dependency with a genuine supported advisory and confirm the resulting Dependabot security pull request is not being delayed by the version-update cooldown; do not treat a simulated alert as evidence of GitHub’s security-update behavior. Review the generated pull-request titles and dependency diffs, not just the YAML syntax. Then run the same required checks used by protected branches: clean install, unit and integration tests, build, vulnerability scan, and any lockfile or generated-file check.

Track operational signals after enabling groups: how many packages land in a group, how long pull requests remain open, whether tests identify the failing dependency, and the time from alert to merged remediation. If one grouped pull request regularly stalls because of an unrelated package, split the policy rather than increasing the cooldown. If urgent alerts arrive without a pull request, investigate the security-update setup instead of weakening the version-update rules.

Dependabot groups can make routine maintenance more manageable while preserving a distinct path for security work. Keep the two tracks explicit, keep groups narrow enough to diagnose, and require the repository’s normal evidence before merging either class of update.

Related:

Sources:

Comments