DEV Community

Ahab
Ahab

Posted on • Originally published at indieseek.co

Dependabot Cooldown: Configure the New 3-Day Default

#github #security #devops #productivity

Dependabot cooldown: configure the new 3-day default safely

Quick answer

GitHub now makes Dependabot wait until a package release is at least three days old before opening a version update pull request. The default applies without any cooldown block in .github/dependabot.yml. Dependabot security updates are not delayed.

For most indie repositories, keep the three-day default first. Then change it only when the repository has a clear reason:

ordinary app dependency
-> keep the default 3-day cooldown

high-impact major upgrade
-> consider 14-30 days plus a dedicated review PR

package that must track an external platform immediately
-> add a named exception, not a global opt-out

known vulnerable installed version
-> use the security update path; cooldown does not apply
Enter fullscreen mode Exit fullscreen mode

The practical win is not simply “wait three days.” It is separating release freshness from vulnerability urgency, then requiring evidence before any dependency PR merges.

Who this is for

This guide is for solo developers and small teams using Dependabot version updates for npm, pip, Cargo, Go, Docker, GitHub Actions, or another supported ecosystem.

If an AI coding agent has just suggested a package you have never used, start with the npm package intake checklist before installing it. Cooldown protects automated update timing; it does not prove that a package, maintainer, install script, or transitive dependency is trustworthy.

What changed, and why it matters

On July 14, 2026, GitHub announced a default three-day package cooldown for Dependabot version updates on github.com. GitHub says the change covers all supported ecosystems and will arrive in GitHub Enterprise Server 3.23. Repositories do not need to edit their config to receive the default.

The boundary matters: version updates wait, while security updates continue to open immediately. That means a newly published routine release gets time to accumulate maintainer reports, registry signals, and CI evidence, but a Dependabot security fix is not held behind the same timer.

The default also interacts with your schedule. Dependabot first checks according to schedule.interval, then applies cooldown rules. A weekly schedule plus a three-day cooldown does not guarantee a PR exactly three days after release; the package becomes eligible after the cooldown and appears on a later scheduled check.

Community discussion around the change exposed three recurring questions: whether security patches are delayed, how to exempt a package, and whether default-days: 0 restores immediate updates. GitHub's docs answer the first two and define valid cooldown values as 1 through 90 days, so zero is not a valid setting.

Choose a policy before editing YAML

Use this small policy table instead of copying a “maximum security” config into every repository.

Repository situation Starting policy Why
Small production web app Default 3 days Adds a buffer without creating a large maintenance backlog.
Stable app with sensitive auth or payment code Patch 3, minor 7, major 30 days Gives larger changes more observation time.
Prototype with disposable data Default 3 days Fast enough for iteration; keep tests as the real merge gate.
SDK tied to a fast-moving platform Named exception only Avoid disabling the buffer for unrelated packages.
Unsupported or end-of-life dependency Do not “cool down” the problem Plan replacement; waiting does not reduce structural risk.

Cooldown is an intake control, not a merge control. A seven-day-old malicious release is still malicious, and a one-hour-old legitimate security fix may be urgent. Keep the policy proportional to the consequence of a bad merge.

Ready-to-copy Dependabot configurations

Option 1: accept GitHub's default

If the three-day default fits, no new key is required:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
Enter fullscreen mode Exit fullscreen mode

This is the lowest-maintenance choice. Record the default in your engineering notes so a delayed PR is not mistaken for a broken Dependabot job.

Option 2: use a risk-tiered npm policy

For a maintained production app, this is a reasonable review starting point:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7
      semver-major-days: 30
      semver-minor-days: 7
      semver-patch-days: 3
Enter fullscreen mode Exit fullscreen mode

The daily schedule looks for eligible updates frequently; the cooldown decides when a release becomes eligible. GitHub supports default-days across the documented cooldown ecosystems, while SemVer-specific fields depend on package-manager support. Check the current options table before copying the SemVer fields to Docker, GitHub Actions, Terraform, or another non-SemVer ecosystem.

Option 3: exempt one dependency

Use an exception when a package must track a platform release quickly:

    cooldown:
      default-days: 7
      exclude:
        - "package-that-must-track-latest"
Enter fullscreen mode Exit fullscreen mode

GitHub documents wildcard support and states that exclude wins over include. Keep the exception named and reviewable. Avoid exclude: ["*"] unless the repository intentionally opts out for every dependency; it removes the protection that motivated the default.

The dependency PR merge gate

Cooldown creates observation time. Use that time with a five-part merge gate:

  1. Classify the update. Is it a routine version update, a vulnerability remediation, or a platform compatibility requirement?
  2. Read the release evidence. Check the upstream changelog, repository ownership changes, registry metadata, and reported regressions.
  3. Inspect the actual delta. Review lockfile changes, new transitive packages, install scripts, binary downloads, and permission changes.
  4. Run product-level verification. Test build, startup, the changed integration, and one rollback path. For security-sensitive code, add the GitHub security review workflow without treating AI review as approval.
  5. Merge with a recovery point. Keep the dependency PR focused, preserve a known-good lockfile, and know how to roll back the deployment.

A compact PR evidence block makes the rule repeatable:

Dependency update evidence
- Update class:
- Release age and source:
- Lockfile/transitive review:
- Tests run:
- Rollback path:
Enter fullscreen mode Exit fullscreen mode

Common mistakes

  • Assuming the new default delays Dependabot security updates. It applies to version updates only.
  • Setting default-days: 0. GitHub documents a valid range of 1-90 days.
  • Expecting a PR exactly when the cooldown ends. The configured schedule still controls when Dependabot checks.
  • Applying SemVer-specific fields to an ecosystem that supports only default-days.
  • Exempting every package because one SDK needs fast updates.
  • Treating release age as evidence that a package is safe.
  • Auto-merging a grouped dependency PR without reviewing transitive and lockfile changes.

FAQ

Do I need to change .github/dependabot.yml?

No. GitHub applies the three-day default to version updates even when cooldown is absent. Change the file only if you want a different window or specific exceptions.

Are critical security updates delayed for three days?

No. GitHub explicitly says the default cooldown does not apply to security updates. Still verify that Dependabot security updates are enabled and that branch protection does not leave urgent PRs unattended.

Should an indie app use 3, 7, or 30 days?

Start with three days. Move routine dependencies to seven days if the app has stable release expectations and little need for same-week features. Reserve longer windows for major upgrades or especially sensitive dependency surfaces. The merge gate matters more than maximizing the number.

How do I disable cooldown for one package?

Add its dependency name under cooldown.exclude. Wildcards are supported, and exclusions take precedence over inclusions. Keep the exception narrow and explain why it needs faster intake.

Does cooldown replace sandboxing or package vetting?

No. It only delays eligibility for automated version update PRs. For unfamiliar code, use a sandboxed agent workflow and inspect the package before executing its setup or install scripts.

Sources

Top comments (0)