Dependabot now waits three days: setting up dependency cooldowns properly

In the third week of July 2026, two announcements landed that seem to point in opposite directions. On 20 July the Next.js team published a security release with nine CVEs, four of them high severity, together with the clear instruction to patch immediately. Three days later GitHub announced that Dependabot now lets new package versions sit for three days by default before opening an update PR. Full speed in one message, handbrake in the other.

The contradiction dissolves once you keep the two cases apart, and that distinction is what this post is about. Separating “a known vulnerability is public” from “a new version has shipped” has become the most important fork in any update strategy.

What GitHub changed

Dependabot now applies a three-day waiting period to version updates. When a new version of a package appears, the corresponding pull request is no longer created the same day but 72 hours later at the earliest. This is the new default and active automatically, no configuration changes required.

The crucial exception is stated right alongside it: security updates are exempt from the cooldown and still arrive immediately. As soon as an advisory for one of your dependencies is published, Dependabot does not wait a second, because from that moment attackers know about the flaw too.

Why waiting protects you

GitHub delivers the reasoning with the change, and the numbers are starker than you might expect. The advisory database records around 18 newly catalogued malicious npm packages per day on average. In an analysis of 21 reported incidents from 2018 to 2026, the malicious versions were each pulled within hours of publication. In one case, compromised packages were live for roughly two hours before the community caught them.

Photo: nate_dumlao / Unsplash

That is the pattern of almost every supply chain attack running through package registries. The malicious code gets injected, gets noticed quickly and gets removed. It is dangerous almost exclusively for the projects that automatically pick it up inside that short window. An independent analysis of ten well-known attacks puts concrete numbers on those windows. The attack on the chalk package was detected in under twelve hours, Nx took four hours, rspack one, tj-actions three days. Eight of the ten attacks had a window of under a week. The big outlier remains xz-utils at around five weeks, a long-game operation that no realistic waiting period would have stopped.

What follows is an unspectacular but effective calculation. If you let new versions sit for three days, you miss nothing except the honour of being first, and you let the majority of attacks run into the void. Seven days would have caught eight of the ten documented cases, fourteen days everything except xz-utils. The protection costs exactly nothing.

The counter-check: the Next.js release

That leaves the question of whether the waiting period tears a hole somewhere else. The Next.js security release of 20 July is the fitting test case. Nine CVEs, four of them high severity, ranging from denial of service to a middleware bypass to server-side request forgery. The patched versions 15.5.21 and 16.2.11 were ready, and every hour of delay after publication was an hour in which attackers could aim the publicly documented flaws at unpatched applications.

This exact case bypasses the cooldown. An advisory exists, so Dependabot creates the update PR immediately, and that PR deserves to be merged and deployed promptly. The handbrake only applies to the normal case without a known security issue. Treating both situations the same gets it wrong in both directions, either you riskily pull fresh versions on day zero, or you leave public vulnerabilities open for days.

Configuring the cooldown

The three-day default can be adjusted per ecosystem in dependabot.yml. An example with a seven-day waiting period for npm packages:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7

Photo: cdr6934 / Unsplash

If you want finer control, let major versions mature longer than patch releases, since a major brings migration work anyway and benefits most from the community having found the early teething problems first. It is worth knowing what the cooldown does not cover: it only slows Dependabot’s own PRs. A manual npm install still pulls the freshest version. To extend the protection there, the package managers have their own knobs, pnpm calls it minimumReleaseAge, Renovate minimum-release-age, uv the exclude-newer flag.

What I make of it for small teams

I look after a good number of projects where updates run through Dependabot, and from that experience the change is overdue. The reflex of installing every new version on release day comes from a time when the biggest risk was outdated packages. That has flipped. Outdated packages remain a problem, but the most acute danger in the npm ecosystem today is the too-fresh version nobody has looked at yet.

For small teams and solo developers the cooldown is a gift, because it is the one protective measure that creates zero ongoing work. No extra tool, no dashboard, no process. The three-day default is deliberately cautious, and if you have no reason to chase maximum freshness, you can set it to seven days with a clear conscience. The other half of the bargain then needs to be taken seriously though: security alerts belong switched on, and when a real security update lands, it is due now, not eventually.

Bottom line, this is a rare kind of security measure, one that removes work instead of adding it. Three days of patience for routine updates, zero patience for known vulnerabilities. The normal case does not need more strategy than that.

If nobody has installed updates in your project for months, or you are not sure whether Dependabot and security alerts are even active, feel free to get in touch. I will take a look and set up the update process so it runs safely without daily attention.