Delay Dependabot Version PRs Before Fresh Packages Hit Your Build

Confirmed: GitHub now waits three days before Dependabot opens a version update pull request for a newly published package release. The default applies across supported ecosystems on github.com and needs no repository configuration. Security updates still open immediately, so the change slows routine version bumps without delaying urgent vulnerability fixes.

What changed

GitHub announced the new default on July 14, 2026. Dependabot version updates now wait until a release has been available in its package registry for at least three days before opening a pull request.

The cooldown is automatic. Teams can keep the default, change the window, or opt out with the cooldown option in .github/dependabot.yml. GitHub says the default applies to all supported ecosystems on github.com and will reach GitHub Enterprise Server 3.23.

Why this is early

The source is GitHub's own changelog, published July 14, 2026. GitHub names cooldown as the supported Dependabot control for changing the delay or opting out.

The independent context is the supply-chain timing problem. StepSecurity's recent write-up argues that freshly published dependency versions are a risky adoption window because malicious packages can reach automated update flows before the ecosystem has time to detect and remove them. Hacker News activity around the GitHub post shows immediate developer attention, but LinkLoot treats that as signal, not proof.

Key takeaways

• Dependabot version update PRs now wait three days by default.
• Security update PRs still open immediately.
• Teams can override or disable the default with cooldown in dependabot.yml.
• The change reduces exposure to compromised or broken releases that are discovered shortly after publication.
• It does not replace review, lockfile checks, provenance review, or package registry monitoring.

Availability and access

The default is active for Dependabot version updates on github.com. GitHub says the same behavior will take effect in GitHub Enterprise Server 3.23.

Repositories that already use custom Dependabot timing should check whether their cooldown rules still match the team's risk tolerance. Fast-moving teams may keep shorter windows for low-risk packages. Regulated or security-sensitive teams may want longer delays for production dependencies, infrastructure tooling, or packages that run in CI.

Practical LinkLoot angle

This is a useful default because it changes the first mile of dependency automation. A three-day pause gives maintainers, scanners, and community reporting more time to flag a bad release before it enters the next routine update PR.

Use it as a baseline, not the whole control. Pair Dependabot cooldowns with grouped PRs, package provenance checks, CI isolation, lockfile diff review, and a clear exception path for security updates. For agent-assisted dependency work, keep the review boundary explicit: the agent can inspect, test, and summarize, but a maintainer should approve production dependency changes.

For broader automation patterns, see LinkLoot's guide to agent workflows: /guides/ai-workflow-automation.

What to verify before you act

• Check whether each repository already defines a cooldown block in .github/dependabot.yml.
• Confirm that security update PRs still arrive immediately in your setup.
• Decide whether high-risk ecosystems need a longer cooldown than three days.
• Review grouping rules so delayed updates arrive in batches your team can actually inspect.
• Test whether internal package registries and private dependencies need separate rules.

Source check

Confirmed by:

• GitHub Changelog: the default three-day Dependabot version update cooldown, the security-update exception, supported ecosystems on github.com, and GHES 3.23 timing.

Early signal / context:

• StepSecurity: supply-chain context for why package cooldowns reduce fresh-release risk.
• Hacker News: developer attention signal around the GitHub announcement, not a primary source.