Dependabot's 3-Day Cooldown: Why Waiting Is Now Safer

The new Dependabot cooldown is the rare security default that costs you almost nothing and buys you real protection. As of GitHub's announcement, Dependabot now waits three days before opening a pull request for a routine version update, so a freshly published release has time to be scrutinised before it lands in your build.

I read the reasoning in GitHub's post, The case for a cooldown, and I think the interesting part isn't the feature. It's what the default admits about how the ecosystem actually works.

---

🕒 What actually changed

Nothing about your dependencies changed. What changed is Dependabot's default sense of timing.

• Version updates (keeping things current) now wait a default three days before a PR opens.
• Security updates still open immediately, because they patch vulnerabilities that are already public. Waiting there would help attackers, not you.
• You control the delay with a cooldown option in dependabot.yml.

Update type	Old behaviour	New default
Routine version bump	PR within minutes	PR after 3 days
Security patch	Immediate	Immediate (unchanged)

Key takeaway: The cooldown only slows down "nice to have" updates. It never delays a real security fix. That split is the whole point.

---

🔍 The problem it quietly admits

The uncomfortable truth behind this default is that a brand-new package version is not automatically trustworthy. GitHub's own numbers make the case:

• In the year ending May 2026, the GitHub Advisory Database published 6,500+ npm malware advisories — roughly 18 new malicious packages every day.
• A review of 21 supply chain incidents from 2018 to 2026 found that malicious versions were typically caught within hours of being published.
• In a September 2025 incident, an attacker compromised an npm maintainer and pushed poisoned versions that stayed live for around two hours.

Two hours is nothing to a human. But it is an eternity to an automated pipeline that pulls the newest version within minutes of publication. As GitHub puts it:

"A cooldown changes that math. Waiting a few days before adopting a new release gives maintainers, security researchers, and automated scanners time to spot a malicious version."

That is the insight. The defence here is not clever code. It is patience, applied by default.

---

🌐 Why this matters more if you're a solo dev in Sri Lanka

If you run a big company, you probably had internal policies, staging soaks, and a security team catching bad releases before they shipped. A three-day wait just formalises what you were already doing.

If you're a student, a freelancer, or a two-person team here, you had none of that. Your CI merged the newest version at 2am and deployed it. You were relying on the entire internet noticing a bad package faster than your pipeline did.

• Packages like chalk and debug see around 2 billion weekly downloads. When one of those is poisoned, the blast radius is enormous, and small projects are in it too.
• Time is the one security control that is completely free. You don't need a scanner subscription or a dedicated engineer to benefit from three days of other people looking.
• The default now protects the people who were least protected, without asking them to configure anything.

Bottom line: This change hands small teams the "someone else will catch it first" safety that big orgs bought with process. You get it for the price of updating a little later.

---

🛠️ Tuning the cooldown for your project

Three days is a default, not a law. You can shorten it for fast-moving internal libraries or lengthen it for anything sensitive. A rough starting point:

Dependency type	Suggested wait	Why
Core framework / widely-used lib	3–7 days	Big blast radius; let the crowd vet it
Small utility packages	3 days	Default is fine
Your own internal packages	0–1 day	You already trust the source

A minimal config looks like this:

# dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 3

A few habits that pair well with the cooldown:

1. Read the changelog before merging, even after the wait. A quiet three days doesn't guarantee safety.
2. Compare the diff between your locked version and the new one — a good time to paste two package.json or lockfile snippets into our text diff checker and eyeball what actually changed.
3. Keep security updates on immediate. Don't let a blanket cooldown accidentally slow down real patches.

---

What this means for you

The cooldown is a small default with a big idea behind it: for routine updates, newer is not safer — it's the opposite, at least for the first few days. Attackers race to get poisoned versions into pipelines before anyone notices. A short wait breaks that race, and it does so for free.

• If you use Dependabot, you likely don't need to do anything — the three-day default is already working for you.
• If you want tighter control, set a cooldown per ecosystem in dependabot.yml.
• If you don't use Dependabot yet and you ship on npm, this is a strong nudge to turn it on. The safest update is often the one you take a little later, after the rest of us have kicked the tyres.

I like defaults that protect the people who can't afford a security team. This is one of them.