The case for a cooldown: Why Dependabot now waits before issuing version updates

Dependabot now applies a default three-day cooldown before opening version update pull requests. GitHub described the change in a blog post titled The case for a cooldown: Why Dependabot now waits before issuing version updates. The wait is deliberate: it gives maintainers and security researchers time to find and fix problems in a new release before that release lands in consumer repositories.

The mechanics are straightforward. When a dependency publishes a new version, Dependabot no longer files a version-update pull request immediately. Instead it holds for three days by default, then issues the update request if the version still qualifies. The cooldown targets version updates specifically so the automation still moves dependency bumps forward, but not at the same pace as the moment of release.

For engineers and maintainers, that delay changes how automated dependency hygiene interacts with release risk. A pull request that arrives the hour a package ships can pull in a version that still has unresolved findings. Waiting three days reduces the chance that CI merges or auto-merge rules absorb a release before maintainers or researchers have had a window to respond. Teams that treat Dependabot as a near-real-time upgrade conveyor will see fewer same-day version bumps and a slightly longer path from publish to proposed upgrade.

In the broader dependency-update landscape, tools compete on speed of detection and on how safely they promote new versions into pull requests. An immediate open maximizes freshness; a cooldown prioritizes a short cooling period after release. GitHub’s default choice signals that the cost of early adoption of a flawed version can outweigh the benefit of upgrading on day zero, at least for routine version updates rather than every class of Dependabot change.

The practical takeaway is to expect version-update pull requests to lag new releases by about three days under the new default, and to plan review and merge habits around that lag. Watch whether your repositories keep the default cooldown or override it for packages you must track more tightly, and whether security-driven updates remain on a faster path than ordinary version bumps. If a release is known-bad within the cooldown window, the delay is exactly the buffer that keeps it out of your tree until maintainers or researchers act.