On Cooldowns and Dependabot Tuning

Tue, 19 May 2026 00:00:00 +0000

"Iceberg" by longhorndave is licensed under CC BY 2.0 .

Dependabot’s defaults can make it look like an agent of chaos. There are a couple of things you can do to turn down the churn from 11.

Cooldowns
#

The idea behind cooldowns is essentially that unless you’re constantly in YOLO mode, you probably don’t need something that was released to the world 5 minutes or even 5 days ago. Yes, there are exceptions (security updates, some brand new thing, etc). Just waiting a few days (or a week) can reduce your exposure to supply chain attacks because a large percentage of compromised packages will have been discovered in the hours/days after a release. It’s not a silver bullet, but it mitigates your exposure to some extent.

Dependabot groups
#

The idea behind Dependabot groups is that you have an escape hatch out of Dependabot pull request hell, where X pull requests are opened that all touch the same files, generally require rebasing if you merge them serially, and sometimes break your CI because they should have been bundled together.

If you’ve ever been in the position of Dependabot proposing major version upgrades to the upload-artifact action and the download-artifact action in discrete pull requests, you probably know what I’m talking about. Neither PR on its own will pass CI. Merging either PR breaks your top level CI. You either need to fix this manually by combining the PRs before merge or merge both broken PRs individually and hope for the best. Similarly, if you have a bunch of different minor version updates to your npm dependencies, which all touch the same lockfile, you may also appreciate being able to group your dependencies.

The skill
#

I have too many repositories to want to manage this by hand, especially when I have a number of slightly different dependabot configs. There’s not necessarily a one-size-fits-all solution. So, a good fit for me is to use a Claude skill to update my deps.¹ My “tune dependabot” skill will examine a dependabot config and apply cooldowns as well as groups, where needed. If the config does not yet exist, it’s happy to create a new one from scratch. For me this is a quality of life thing as I have accumulated too many repositories for this kind of banal work to be enjoyable. In addition to the security benefits, it also reduces some of the friction that comes with having to merge a lot of dependabot pull requests on an ongoing basis.

A tuned config
#

Here’s a sample, tuned config file. GitHub Actions gets two groups: major version bumps are batched together so that changes to things like upload-artifact and download-artifact can be merged together, with minor and patch updates bundled into their own pull request. The gomod and npm ecosystems only group minor and patch updates, which allows the major version bumps to be tested in isolation. Every ecosystem gets a one week cooldown period.

version: 2
updates:
 - package-ecosystem: "github-actions"
 directory: "/"
 schedule:
 interval: weekly
 groups:
 major-updates:
 patterns:
 - "*"
 update-types:
 - "major"
 minor-and-patch:
 patterns:
 - "*"
 update-types:
 - "minor"
 - "patch"
 cooldown:
 default-days: 7
 - package-ecosystem: gomod
 directory: "/go"
 schedule:
 interval: weekly
 open-pull-requests-limit: 10
 groups:
 minor-and-patch:
 patterns:
 - "*"
 update-types:
 - "minor"
 - "patch"
 cooldown:
 default-days: 7
 - package-ecosystem: npm
 directory: "/"
 schedule:
 interval: weekly
 open-pull-requests-limit: 10
 groups:
 minor-and-patch:
 patterns:
 - "*"
 update-types:
 - "minor"
 - "patch"
 cooldown:
 default-days: 7

This gets me fewer rebases, boring CI, and a few extra days of waiting while the rest of the world identifies the bad actors.

Written with Superpowers, as usual. ↩︎

Read on website

Dependabot on olafalders.com

On Cooldowns and Dependabot Tuning

Cooldowns #

Dependabot groups #

The skill #

A tuned config #

Cooldowns
#

Dependabot groups
#

The skill
#

A tuned config
#