Updating all dependencies immediately after release carries risks as the package may have been compromised. The package may also still have "teething problems", especially for new features.
Aside from known security releases, waiting a few days/weeks is often the less risky option, in hopes that someone else find a potential problems before we update the package.
This is called a "cooldown" period.

Or as Zizmor describes it:
> Performing updates without an appropriate cooldown presents both stability and supply-chain security risks:
> * **Stability**: updating to the newest version of a dependency immediately after its release increases the risk of breakage, since new releases may contain regressions or other issues that other users have not yet discovered.
> * **Supply-chain security**: package compromises are frequently _opportunistic_, meaning that the attacker expects to have their compromised version taken down by the packaging ecosystem relatively quickly. Updating immediately to a newly released version increases the risk of automatically pulling in a compromised version before it can be taken down.

Of course, for frequently released packages, this `cooldown` period shouldn't be too long, as otherwise the package will never update, as the "latest" release will always be too young.

Since July 2025, the Dependabot config offers the possibility to add a `cooldown` period to delay the creation of dependency update PRs based on the number days since the release came out.
Depending on the ecosystem, this `cooldown` period can be configured with more or less flexibility (only `default-days` or semver based differentiation). _Unfortunately, the `github-actions` ecosystem only allows the `default-days` option._

Since then (July 2026), GitHub, in their wisdom, has introduced a standard "cooldown" period for all packages of three days.
This is counter-productive as that means that the chances of a compromise being found within the first three days have decreased significantly.

The Zizmor tool recommends a `cooldown` of seven days, which, with increased adoption of zizmor, again decreases the likelihood of a compromise being found before it reaches this package.

With all this in mind, I propose setting a `cooldown` period of 10 days.

Refs:
* https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/
* https://github.blog/changelog/2026-07-14-dependabot-version-updates-introduce-default-package-cooldown/
* https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference#cooldown-
* https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates
* https://docs.zizmor.sh/audits/#dependabot-cooldown