Every time your bot merges a two-hour-old release into main, you are trusting a stranger's freshly published tarball to be the same one everyone else is looking at. Sometimes that release is a real bugfix. Sometimes it is a maintainer who fat-fingered a token, or an attacker who did not, and either way your CI cheerfully rebases against it before anyone had a chance to notice.
On 2026-07-14, GitHub added a pause. Not a big one. But a real one.
The actual change
Dependabot version updates now sit on their hands for three days after a package is published. According to the GitHub Changelog, a release has to have been available on its registry for at least that long before Dependabot will open a version-update pull request against your repository. The cooldown is on by default and requires no configuration. It applies across every ecosystem Dependabot supports on github.com, and GitHub Enterprise Server picks it up in GHES 3.23.
Security updates are exempt. If a fix for a known vulnerability lands, Dependabot will still open the PR the moment it can, because a three-day delay on the patch defeats the entire point of shipping the patch.
That single carve-out is the whole design.
Why three days is doing so much work
Three days is not enough time to audit a package. Nobody is pretending otherwise. What three days is enough for is someone else to notice.
Most malicious releases that end up on a public registry get pulled quickly once security researchers, downstream maintainers, or the registry's own scanners spot the pattern. The typosquats, the hijacked accounts, the crypto miners buried in a postinstall script: they all rely on being pulled into build automation before the pattern is visible. Dependabot's old default was to be that automation. Its new default is to let the pattern show up first.
You can read this change as GitHub quietly admitting that "always up to date" was the wrong marketing promise for a supply-chain tool.
The knob, and what shifted about it
Cooldown is not new to Dependabot; it has been configurable for a while. What changed is which side of the switch ships out of the box. If you already had a cooldown block in your dependabot.yml, that block wins and nothing surprising happens. If you didn't, you now have one implicitly, and every ecosystem you update inherits it.
The config surface stays the same idiom you already know. In your .github/dependabot.yml:
version: 2
updates:
- package-ecosystem: <ecosystem>
directory: /
schedule:
interval: daily
cooldown:
default-days: <number>
You can dial the number up if you want a longer sniff test (a week is a common shape for large monoliths), set it to zero to opt back into the old always-fresh behaviour, or tune per-dependency for the internal packages you actually control. Security updates ignore all of this and still fire on discovery. That is the important sentence.
Where this pinches in practice
There are two operational places you will feel this.
First, if any part of your build assumes that "there is a Dependabot PR" is a proxy for "a new upstream release exists," that assumption is now three days behind reality. Release radars, changelog-following dashboards, the workflow that pings a Slack channel the day a new dependency drops: expect a lag. Fine, but rewrite the runbook.
Second, reproducible builds get quietly friendlier. A cooldown means the version resolved by your package manager on Monday is a lot more likely to be the version your CI resolved on Friday. Lockfiles were already supposed to guarantee that, and the disciplined ones do, but every team has that one job that runs without a lock, or with a force flag, or against a floating range. Those jobs churn less now.
The pinch that gets less airtime: if a legitimate, urgent, non-security release comes out (a performance fix, a compatibility patch for a runtime you upgraded yesterday), you have to open the PR yourself for three days. Manual work is still work.
What a cooldown does not catch
A cooldown is a broad-spectrum filter. It buys time; it does not verify anything.
It will not tell you the release was signed by the same key as the previous one. It will not check the SBOM. It will not notice that a maintainer's account was compromised a week ago and the malicious release was carefully aged before being cut. It will not save you from a dependency whose very first release is malicious and has no history to sit on.
Sigstore attestations, provenance verification, lockfile pinning, allowlist registries, and a healthy allergy to postinstall scripts still do the load-bearing work. A three-day wait is a coarse extra layer on top of them. Treat it that way.
The kicker
Package registries used to be a firehose you drank from. They are becoming something you queue against, with your CI as the bouncer at the door. Three days is not a big queue.
It is a queue.
Top comments (0)