The 14-day soak window
Why we deliberately wait 14 days before adopting any new dependency version, how security advisories bypass the hold, and what the delay actually costs.
How fast should you adopt a new dependency version?
For most teams, the answer is “as fast as possible”. Renovate even defaults to that. A new version drops, a PR opens, and you merge.
We don’t. We wait 14 days.
It is the one setting most teams skip, and the highest-value one we have configured. Every new dependency version sits in our base preset’s hold before Renovate will open a pull request:
{
// Wait 14 days after a release before opening a PR. Soaks each new version
// for community/security feedback so we don't ship a CVE the moment it lands.
// Security advisories bypass this automatically (Renovate built-in behavior).
"minimumReleaseAge": "14 days"
}Why 14 days
A version released five minutes ago has been tested by the maintainer’s team and a few brave early adopters. After 14 days, it has been tested by everyone who isn’t us.
First releases of a new major sometimes ship with bugs the maintainer didn’t catch (provider regressions, breaking changes that were not supposed to be breaking). Two weeks is enough for the community to surface them, usually in an issue tracker, occasionally in a blog post written by somebody having a much worse week than we are.
CVEs occasionally get introduced in the same version that fixes other CVEs. A patch release is not automatically safer than the thing it patched. The soak window gives the security community time to flag it.
None of these require us to do anything. That is the appeal. The soak window is not a process, it is a delay, and delays scale to any number of repositories without anyone reviewing anything.
The honest tradeoff
We delay CVE patches by 14 days.
That is the real cost, and it would be a bad trade if it were true unconditionally. It isn’t: Renovate auto-bypasses minimumReleaseAge for versions that fix a known security advisory. Security fixes still open a pull request immediately. Everything else waits.
So the actual trade is narrower than it first looks. Known vulnerabilities jump the queue. Unknown ones, the ones nobody has flagged yet, are precisely the case the soak window helps with, because the flagging is what happens during those 14 days.
What it does not cover
The soak window is about time, not correctness. It does not test anything. A version that has been public for a year and is still broken for our specific usage will sail straight through.
It buys distance from the release event, nothing more. That happens to be the cheapest useful thing you can buy in dependency management, which is why it is worth one line of config.
The wider preset architecture this lives in is the subject of Renovate at Scale.
Originally published on LinkedIn, May 2026.