Keep the three-day default for most dependencies, preserve immediate security updates, and shorten the window only when the cost of waiting is understood.
Update — August 12, 2026: This guide now distinguishes the default delay from the check schedule, explains per-dependency exceptions, and adds a way to validate the automation before auto-merge.
Dependabot version updates now wait until a package release has been available in its registry for at least three days before opening a pull request. GitHub enabled the cooldown by default without requiring a configuration change.
The delay is a response to a familiar supply-chain problem: an automated update can deliver a compromised or badly broken release faster than maintainers and users can detect it. Waiting creates an observation window without turning updates off.
Security fixes are not delayed
The default applies to version updates, not Dependabot security updates. When GitHub identifies a vulnerable dependency and can prepare a security update, that pull request still opens immediately.
This distinction matters. A blanket delay would trade supply-chain caution for known-vulnerability exposure. The new default separates routine freshness from urgent remediation.
When to change the window
Teams can set another duration or opt out through the cooldown option in `.github/dependabot.yml`. A shorter window can make sense for an internal package you control or a fast-moving dependency with strong testing. A longer window can suit low-change systems where stability is more valuable than immediate features.
Do not choose the duration by instinct alone. Record how often updates fail, how quickly upstream regressions are discovered, and whether your test suite catches the failure modes that matter.
The cooldown is not the update schedule
Dependabot still needs a `dependabot.yml` file for version updates, and that file determines which ecosystems and directories it watches as well as whether it checks daily, weekly, or monthly. The cooldown answers a different question: how long after a release becomes available Dependabot may consider it for a routine update.
Keep those controls separate when diagnosing a late pull request. A daily schedule with a three-day cooldown is not equivalent to a weekly schedule with no cooldown. Check the repository configuration and Dependabot status before assuming that a package was skipped.
Make exceptions narrow and reviewable
GitHub documents cooldown options that can be applied to selected dependencies or releases while leaving security updates outside the delay. That supports a safer policy than turning the delay off for an entire ecosystem: keep the default for general packages, then document a small exception for a dependency whose release and test process you understand.
Before changing the setting, compare a few recent Dependabot pull requests with the actual registry release times, CI result, and merge outcome. If the reason is only “we prefer freshness,” keep the three-day default. If a service-level commitment requires a shorter window, name the owner, the test evidence, and the date to reconsider it.
- Keep security-update review and auto-merge rules separate from routine version updates.
- Use a short allowlist of justified exceptions instead of a global opt-out.
- Verify lockfile changes, test results, and release notes before enabling routine auto-merge.
- Record when the cooldown policy was last reviewed and which repositories use exceptions.
- Inspect Dependabot status when the expected pull request does not appear.
Review the automation around Dependabot
A cooldown is not a substitute for review. Confirm that CI runs on dependency pull requests, lockfiles are included, release notes are accessible, and auto-merge rules distinguish routine patches from major or security-sensitive packages. The default covers supported ecosystems on GitHub.com and is planned for GitHub Enterprise Server 3.23.
This article explains the practical implications of the primary material below. PatchMemo does not publish vendor copy as editorial coverage and does not accept payment for positive coverage.
PatchMemo independently selects and evaluates the topics it covers. Analysis and recommendations are ours; sources are linked so readers can check the underlying claims. We clearly label sponsorships and affiliate relationships, and neither determines coverage or conclusions.
