GitHub gives Dependabot version updates a three-day default package cooldown

GitHub has changed the default behavior of Dependabot version updates so that routine dependency bump pull requests wait until a newly released package version has been available in its registry for at least three days. The July 14 GitHub Changelog post frames the delay as a supply-chain safety measure: when a package release is compromised, broken, or quickly pulled back by maintainers, a short waiting period can give the wider ecosystem time to surface warning signs before automated update workflows put that release in front of developers.

The change applies without new configuration to Dependabot version updates across all supported ecosystems on github.com. GitHub says it will also arrive in GitHub Enterprise Server 3.23. Security updates are explicitly excluded from the delay, so Dependabot should still open urgent remediation pull requests immediately when a vulnerable dependency needs a patched version.

What changes for maintainers

For many repositories, the practical effect is a less immediate stream of routine version-bump pull requests. Instead of chasing every fresh package release as soon as it appears, Dependabot will wait through a three-day cooling-off period before opening the update. That can reduce the chance that teams merge a malicious or unstable version during the early window when package registries, maintainers, and downstream users are still discovering problems.

GitHub is not removing maintainer control. Projects can still use the cooldown option in .github/dependabot.yml to choose a different waiting period or opt out entirely. That matters for teams with different risk profiles: some may want longer delays for low-priority libraries, while others may need rapid non-security updates for actively developed internal platforms or compatibility testing.

Why it matters

The update lands amid continued concern over software supply-chain attacks that abuse the trust developers place in package managers and automated dependency tools. Automated update bots are valuable because they keep dependencies moving, but they can also accelerate the spread of a bad release if a repository merges too quickly. GitHub's new default tries to make the safer path the ordinary one for routine updates, while preserving the fast path for security fixes.

For security teams, the key detail is the distinction between version updates and security updates. A blanket delay would be risky if it slowed patches for known vulnerabilities. GitHub's approach instead delays ordinary freshness updates while leaving vulnerability-driven fixes immediate, giving organizations a new default that is cautious without turning Dependabot into a bottleneck for critical remediation.

Sources

• github.blog

Cover photo by Jakub Zerdzicki on Pexels, used under the Pexels License.