Not by default. A cooldown delays version updates, meaning routine upgrades to newer releases. In the update bots documented below, security fixes are handled by a separate path that the cooldown does not apply to. Check your own configuration, because one stray setting can quietly add days to every fix.
What a cooldown is
A cooldown (also called a minimum release age) tells an update bot to wait a set time after a new version is published before proposing it. The idea is simple: if a release turns out to be malicious or broken, the community often notices within days, and waiting lets you skip it.
The cost is the same wait applied to the wrong kind of update. If the version you need contains a vulnerability fix, every day of cooldown is a day of exposure. So the real question is whether your tooling separates the two.
How two common bots treat it
GitHub's Dependabot documentation says the cooldown option is available for version updates, not security updates. It also says Dependabot applies a default cooldown of 3 days to version updates even when you have not configured one, and that this default does not apply to security updates.
Renovate's documentation lists a separate vulnerabilityAlerts block, described as the config applied when a PR is needed because of a vulnerability in the existing package version. In its listed defaults, minimumReleaseAge is null, prCreation is immediate and the schedule list is empty. You can override the block, so a team that sets a global cooldown and then copies it into vulnerability settings reintroduces the delay.
| Setting | Version update path | Security update path |
|---|---|---|
| Dependabot cooldown | Applies, 3 day default | Does not apply, per docs |
| Renovate minimumReleaseAge | Applies when set | Default null in vulnerabilityAlerts |
| Schedule limits | Often weekly or similar | Renovate default is empty (no limit) |
Where the hidden delay still comes from
Even with the cooldown out of the way, three things can stretch the window.
- The fix is brand new. A cooldown does not matter if the patched version was released an hour ago and you want to inspect it first. Decide in advance how much review a fresh security release gets.
- Schedules. A weekly schedule on version updates is fine. The same schedule applied to security pull requests is not.
- Review and deploy queues. The bot may open the PR in minutes while the PR waits days for a human.
A safe default policy
Write the rule down in one paragraph:
- Routine updates wait for the cooldown.
- Security fixes skip it, open immediately and get a fast review lane.
- A security fix released within the last day still gets a quick look at the release notes and the diff of the lockfile.
- Anyone can see which path a PR came from, through a label or title tag. Renovate, for example, puts a [SECURITY] suffix in the PR title for vulnerability PRs.
That keeps the supply chain benefit of waiting for routine releases without paying for it on the updates where time matters.
How to verify your setup
Open one recent security PR and compare three timestamps: the advisory date, the PR creation date and the merge date. If the gap between advisory and PR creation is large, look at schedules and cooldown settings. If the gap between PR creation and merge is large, the problem is review capacity, which no bot setting fixes.
Try it yourself
Open the demo and look at how a fix becomes available for a flagged package, then compare that moment with when your own bot would have opened a PR.
Click through it at your own pace, or open it full screen.
Safeguard ships dependency scanning and reachability analysis, and fix pull requests that stay off until you turn them on. You can run a free scan at gold.safeguard.sh/scan to see which of your dependencies have fixes available today.
Quick check
Does a cooldown make me less secure?
It protects against bad new releases and costs you time on good ones. Applied just to routine updates, the trade is reasonable. Applied to security fixes, it extends exposure.
Should a security fix ever wait?
Briefly, to read the release notes and check the lockfile diff. Not for a fixed number of days.
Sources
Last reviewed: 19 October 2026.
