Quick answer: Starting July 14, 2026, GitHub Dependabot waits until a package release has been available in its registry for at least three days before opening a version update pull request. You do not need to edit your repository to get the new default. Security updates are not delayed and continue to open immediately.
What repository maintainers need to do
- Keep the safer default: make no configuration change.
- Use a longer or shorter delay: add a
cooldownblock to each relevant update entry in.github/dependabot.yml. - Remove the delay: set
default-days: 0. Do this only if immediate version-update pull requests are more important than the extra observation window. - Do not treat the delay as a security scanner: continue using tests, code review, lockfiles, code scanning, secret scanning and dependency review where appropriate.
Copy-ready dependabot.yml examples
1. Keep GitHub’s three-day default
No new cooldown setting is required. A normal npm configuration can remain as it is:
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"The schedule controls when Dependabot checks for updates; the cooldown controls how old a new package release must be before a version-update pull request is created.
2. Set a seven-day cooldown for all npm version updates
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
cooldown:
default-days: 7This changes the minimum package age for that npm update entry to seven days. It still does not delay Dependabot security updates.
3. Use different delays for major, minor and patch releases
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: 3This policy gives major releases a longer observation period while allowing patch releases sooner. GitHub documents the SemVer-specific options for supported package managers.
4. Exclude a time-sensitive dependency
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
cooldown:
default-days: 7
include:
- "*"
exclude:
- "your-time-sensitive-package"Replace the example dependency name with a real package that your team has intentionally approved for faster version updates. GitHub’s configuration also supports wildcards in include and exclude.
5. Opt out of the default cooldown
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
cooldown:
default-days: 0GitHub’s Dependabot team confirms that setting the cooldown to zero removes the delay. Before opting out, document why immediate version updates are necessary and make sure your automated tests and review controls are strong.
What changed on July 14, 2026?
| Item | New behavior |
|---|---|
| Dependabot version updates on GitHub.com | New package releases wait at least three days by default before a PR is opened. |
| Dependabot security updates | Not delayed; they continue to open immediately. |
| Existing repositories | No configuration change is required to receive the default. |
| Custom policy | Use cooldown in .github/dependabot.yml. |
| GitHub Enterprise Server | GitHub says the default will take effect in GHES 3.23. |
| Ecosystems | GitHub says the default applies across supported Dependabot ecosystems on GitHub.com. |
Why GitHub added the default delay
A newly published dependency can be broken or compromised before maintainers and the wider community have time to detect the problem. Dependabot’s new default adds a short observation window before routine version-update pull requests appear. It is intended to reduce the chance of adopting a harmful release immediately after publication.
The delay is a risk-reduction measure, not proof that a three-day-old package is safe. A malicious release may remain undetected for longer, and a legitimate urgent fix may need faster adoption. Teams should combine package-age policies with CI tests, human review and appropriate software supply-chain controls.
Recommended policy by project type
| Project | Practical starting point |
|---|---|
| Typical application | Keep the three-day default, then review after a few update cycles. |
| High-risk production system | Consider a longer cooldown for major/minor version updates, backed by a documented exception process. |
| Fast-moving library or compatibility test project | Use a shorter delay or targeted exclusions only where rapid testing is an explicit requirement. |
| Repository with weak tests | Do not use cooldown as a substitute for improving CI and review coverage. |
Five-minute rollout checklist
- Open
.github/dependabot.yml. - Identify every package-ecosystem update entry; cooldown configuration is applied within an entry.
- Decide whether the three-day default fits your release-risk policy.
- If customizing it, add the smallest policy needed and validate the YAML indentation.
- Commit the change through a reviewed pull request.
- Confirm that routine version-update PR timing matches the policy over the next update cycle.
- Keep security updates, tests and scanning enabled.
If you also maintain npm projects, review the related npm v12 migration and supply-chain security checklist.
Frequently asked questions
Does the three-day cooldown delay security updates?
No. GitHub explicitly says the default applies only to version updates. Dependabot security updates continue to open immediately.
Do I need to change dependabot.yml?
No change is needed to use the new three-day default. Edit .github/dependabot.yml only if you want a different cooldown or want to opt out.
How do I disable the Dependabot cooldown?
Add a cooldown block to the relevant update entry and set default-days: 0.
Is cooldown the same as the Dependabot schedule?
No. The schedule controls how often and when Dependabot checks for version updates. Cooldown controls the minimum age of a package release before Dependabot can raise a version-update pull request.
Does this apply to GitHub Enterprise Server?
GitHub says the new default will take effect in GitHub Enterprise Server 3.23.