If Dependabot seems slower to nag you about new package versions lately, that’s not a bug — it’s a deliberate three-day pause, and you now control the dial. As of GitHub’s July 23 announcement, Dependabot waits at least three days after a release is published before opening a version-update pull request. Security updates still arrive instantly. Everything else sits in a deliberate quarantine window — and with a few lines of YAML you can stretch it, shrink it, or carve out exceptions for packages you trust.
This walkthrough covers what the new default actually does, then works through the cooldown block in dependabot.yml step by step: setting your own window, splitting it by semver level, and exempting internal packages so your own releases don’t get stuck in the waiting room.
Why GitHub pumped the brakes
The motivating incident is worth understanding because it explains every design decision that follows. In September 2025, an attacker phished the credentials of a single npm maintainer and published booby-trapped versions of chalk, debug, and around a dozen other packages that together see more than 2 billion downloads a week. The poisoned code rewrote cryptocurrency wallet addresses inside any browser app that loaded it. The community caught it and npm pulled the versions in roughly two hours.
Two hours is a fast response by human standards — and still an eternity for automated tooling built to grab the newest release the moment it lands. A bot can see the new version, open a pull request, and put it in front of your team well inside that window. GitHub’s product manager for Dependabot, Carlin Cherry, points out that the same short-lifespan pattern held for compromised builds of Solana web3.js, Axios, ua-parser-js, and Ledger Connect Kit: each was pulled within hours of publication. A review of 21 widely reported supply-chain incidents between 2018 and 2026 found a cooldown would have filtered out the majority of these short-lived malicious publishes before anyone installed them.
The scale is not small. The GitHub Advisory Database cataloged more than 6,500 npm malware advisories in the year ending May 2026 — up from roughly 6,200 the year before, or about 18 newly cataloged malicious npm packages every day. Waiting three days moves you past the window where most of these attacks live and die.
One boundary to keep straight before touching any config: Dependabot does two different jobs. Security updates respond to a published advisory and still open immediately — delaying those would hold back a fix for a flaw that is already public. Version updates keep you current as releases ship, and only these are subject to the cooldown. Everything below applies to version updates only.
Step 1: Find (or create) your dependabot.yml
The cooldown is on by default, so if the three-day window suits you, you’re done — no configuration needed, even if you have no dependabot.yml at all. To customize it, you need the config file, which lives at .github/dependabot.yml in your repository root.
A minimal file for an npm project looks like this:
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
If you already have one, you’ll be adding a cooldown block under each package-ecosystem entry you want to tune. The Dependabot options reference documents every key; the cooldown options sit alongside schedule, allow, and ignore at the same indentation level.
Step 2: Set your own default window
The simplest customization is default-days — one number that replaces the built-in three-day wait for every dependency in that ecosystem:
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
cooldown:
default-days: 7
With this in place, Dependabot still checks for updates on your configured schedule, but a release only becomes eligible once it has been public for seven days. Anything younger is skipped on that run and picked up on a later one, after its cooldown expires.
Which direction should you turn the dial? GitHub chose three days because it balances two goals: it clears the window where most short-lived malicious publishes get caught, and it doesn’t hold your dependencies back longer than necessary. Other community tooling has independently landed on three days too, though some teams go longer. A conservative production service might run seven days; a fast-moving internal tool might drop to one or two. There’s no wrong answer, just a freshness-versus-scrutiny tradeoff you now get to make explicitly.
Step 3: Split the window by semver level
Not all version bumps carry equal risk appetite. For package managers that support semantic versioning — npm and Yarn, pip, Cargo, Go modules, Maven, Composer, and most of the rest of the supported list — you can set different windows per bump type:
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
cooldown:
default-days: 3
semver-major-days: 14
semver-minor-days: 7
semver-patch-days: 2
The logic here mirrors how most teams already think: patch releases are usually safe bug fixes, so a short window keeps you current; major versions bring breaking changes you weren’t going to rush into anyway, so two weeks of community soak time costs nothing. Any level you don’t specify falls back to default-days.
Note the support caveat: default-days works across every package manager that supports cooldowns at all (the list spans everything from Bundler and NuGet to Docker, Terraform, and GitHub Actions), but the three semver-*-days options only apply where the ecosystem actually uses semver. For ecosystems like Docker image tags, stick to default-days.
Step 4: Exempt the packages you trust
The cooldown treats a release from your own platform team the same as a release from an anonymous npm account — unless you tell it otherwise. The include and exclude lists (up to 150 entries each, wildcards supported) let you scope the cooldown precisely:
cooldown:
default-days: 5
include:
- "*"
exclude:
- "@yourorg/*"
- "internal-design-system"
exclude always wins: a dependency matching both lists is excluded and updates immediately. This is the pattern GitHub suggests for organizations that publish internal packages to a registry — your own releases skip the queue while everything from the public registry serves its waiting period. The inverse also works: use include to apply a cooldown only to a known-risky subset while everything else updates freely.
Step 5: Verify it’s actually working
After committing the change, the behavior shift shows up in what Dependabot doesn’t do. On the next scheduled run, releases younger than your window won’t generate pull requests. You can confirm the config parsed correctly under your repository’s Insights → Dependency graph → Dependabot view, where each ecosystem shows its last check and any config errors. If a fresh release you expected to be delayed shows up as a PR anyway, check whether it arrived as a security update — advisories bypass the cooldown by design, and that’s the correct behavior.
One more interaction worth knowing: cooldowns compose with your existing ignore and allow rules. Filtering happens first, then eligible updates are checked against their cooldown window. Nothing about grouped updates changes either — a grouped PR simply won’t include a dependency still inside its window.
What a cooldown won’t save you from
GitHub is refreshingly direct about the limits. A cooldown is built for one specific attack shape: a malicious version that ships, spreads, and gets caught quickly. It does nothing against backdoors planted in a release and left dormant past your window, a maintainer who goes rogue slowly, or a compromised build system signing legitimate-looking artifacts.
That’s why the announcement frames it as one layer among several, alongside pinning dependencies with lockfiles, disabling install scripts in CI where you can, scoping the tokens in your build pipelines, and actually reviewing update PRs before merging them. The cooldown removes the most time-sensitive path — the one where automation races ahead of human scrutiny — and hands the rest back to your existing defenses.
If the new default behaves oddly in your setup, GitHub is collecting field reports in the Dependabot community discussions. Given that this shipped enabled for every repository on the platform, expect the tuning knobs to get more attention — and possibly more granularity — as feedback lands.
