The New Default Is A Three-Day Pause
On July 14, 2026, GitHub announced that Dependabot version updates now wait until a new release has been available in its registry for at least three days before opening a version update pull request. GitHub says the default applies to version updates, requires no configuration on github.com, and does not delay security updates. That last sentence matters, because otherwise this would be a very fancy way to make teams nervous. GitHub’s changelog explains the new default cooldown.
This is a quiet but sensible correction to the way dependency automation often behaves. For years, many repositories treated “newer” as nearly synonymous with “better.” A bot opened a pull request, CI went green, someone clicked merge, and everyone pretended that a green test suite meant the package ecosystem had been audited by the gods. It had not. It had merely installed.
The cooldown does not make supply-chain risk disappear. It does not prove that a package is safe. It simply creates time for obvious problems to surface: broken releases, pulled packages, compromised maintainer accounts, angry issue threads, emergency patches, and the familiar “please do not install this version” note that appears after half the internet already installed it.
Speed Was Never The Whole Dependency Strategy
Dependency bots solved one real problem and created another. The solved problem: humans are bad at manually checking hundreds of packages across multiple ecosystems. The created problem: once the bot exists, teams start using pull request presence as a proxy for importance. If Dependabot opens it, it feels official. If CI passes, it feels finished. If the diff is mostly a lockfile, it feels boring. Boring changes are where people get lazy.
A three-day wait is useful because ordinary version updates are rarely emergencies. A patch release for a UI helper, a minor release for a formatter, or a new version of a test fixture package usually does not need to land eleven minutes after publication. If it does, that is not a Dependabot problem. That is a release management problem wearing a little robot hat.
The better mental model is simple: dependency updates need lanes. Security fixes get the fast lane. Routine version updates get the normal lane. Major upgrades get the scheduled-work lane. Experimental packages get the suspicious little side road with traffic cones and a person holding a clipboard.
This is the same reason AI coding agents need boundaries before they touch real projects. Automation is useful when it narrows the job and leaves receipts. It is dangerous when it turns “something changed” into “something should be merged.” If your team already treats coding automation as part of the software supply chain, the dependency bot belongs in that same conversation. Notavello has covered the broader pattern in AI coding CLIs as supply chain tools.
Do Not Disable The Cooldown Just Because It Is Annoying
The first bad reaction will be predictable: someone will notice that Dependabot is “late,” then discover the cooldown, then turn it off because the dashboard looks less fresh. This is how teams accidentally optimize for inbox neatness instead of production safety.
The default three-day delay is a reasonable baseline for normal version updates. For many projects, it may even be too short. If you run a serious production app, a longer delay for major upgrades is usually sane. Major versions are where APIs move, defaults change, transitive dependencies shift, and migration guides are written in the gentle tone of someone who knows they ruined your Thursday.
GitHub’s Dependabot documentation says the cooldown option can be configured in dependabot.yml, including separate cooldown periods for default, major, minor, and patch updates where the package manager supports semantic versioning. It also supports include and exclude lists, which means teams can apply stricter rules to risky dependencies and let boring internal tooling move faster. GitHub’s Dependabot options reference documents the cooldown settings.
The point is not to worship the default. The point is to make the delay intentional. If a dependency is low risk and you want it updated immediately, exclude it deliberately. If a package sits near authentication, payments, build tooling, deployment, cryptography, serialization, or code execution, give it more time and more review. A package manager is not a moral authority. It is a vending machine with global write access.
Separate Security Updates From Version Churn
The most important operational detail is that Dependabot’s default cooldown is for version updates, not security updates. That distinction should also exist in your review process.
- Security update: a known vulnerability is being fixed. The question is how fast you can safely patch, test, and deploy.
- Routine patch or minor update: a package has changed. The question is whether the change is useful enough to merge now.
- Major update: the dependency contract may have changed. The question is whether this belongs in planned engineering time.
- Build or deployment dependency update: the change may affect how your software is produced, not just how it runs. Treat it with extra suspicion.
This split prevents a common failure mode: teams get so many routine bot PRs that security PRs become just another tile in the wall. That is backwards. Security updates should be more visible, not buried under twenty lockfile bumps for packages nobody can pronounce.
A good dependency process makes the bot boring without making the review meaningless. Group low-risk updates. Schedule routine updates for a predictable day. Require stronger review for major upgrades. Keep security updates separate. If the team cannot explain why an update matters, that update probably should not be merged during a coffee break.
A Practical Cooldown Policy For Small Teams
If you do not already have a policy, start with something plain. You do not need a security committee, a 47-page document, or a meeting called “Dependency Governance Sync.” Please do not invent that meeting.
| Update Type | Suggested Handling |
|---|---|
| Security updates | Review immediately, test quickly, deploy through the normal emergency or fast-track path. |
| Patch updates | Let the default cooldown run, then group and merge after tests and changelog review. |
| Minor updates | Use a longer cooldown if the dependency is production-critical or close to infrastructure. |
| Major updates | Treat as planned work, not routine bot cleanup. |
| Build, CI, deployment, auth, payment, and crypto packages | Add extra review even when the diff looks tiny. |
For many repositories, a weekly dependency window is better than a constant stream. Let Dependabot collect safe candidates, then review them in one focused pass. This reduces alert fatigue and makes it easier to spot the one update that deserves actual attention.
Also keep a short rollback path. Dependency updates should be easy to revert, especially grouped ones. If a grouped pull request updates twelve packages and production catches fire, you do not want to spend the next hour discovering which package brought matches.
The Real Win Is Slower Automation With Better Receipts
The larger lesson is not about Dependabot alone. It is about automation growing up. The first generation of developer automation chased speed: open the PR faster, autocomplete the code faster, run the tool faster, merge the update faster. The next generation needs to care more about context, timing, and evidence.
A dependency bot should not just say “new version available.” It should help answer: how old is the release, what changed, who published it, whether the package was yanked or republished, whether similar projects are reporting breakage, whether the update touches runtime code or only development tooling, and whether the project has enough tests to notice the difference. Some of that still requires human judgment. Annoying, but reality has persisted despite several attempts to deprecate it.
Dependabot’s cooldown is a small feature, but it nudges teams toward the right habit: do not treat the newest package as the safest package. Fresh releases need air. Maintainers need time to spot mistakes. Users need time to report breakage. Security researchers need time to notice patterns. Your CI pipeline needs time to be more than a ceremonial green check.
Keep the cooldown. Tune it where needed. Make security updates urgent without making every version bump urgent. The best dependency process is not the one that merges fastest. It is the one that lets automation do the boring work while humans still notice when the boring work is carrying a knife.