GitHub's Dependabot playbook: group the version PRs, slow the cadence, keep security fast

For a long time I had a mental filter for the word "Dependabot". If a PR title started with chore(deps):, my eyes slid off it. There were forty-two of them open on our main service. Some of them had been open since March. I would have muted the whole app if it did not, once every few months, also open the PR that fixed the actual CVE we cared about.

GitHub published a guide on 2026-07-29 that puts a name on the problem and offers the config I should have written two years ago. The post, titled "Tame Dependabot: Group your updates, slow the cadence, keep security fast," treats Dependabot as a set of controls you configure on the repo. Three levers, and none of them is an off switch.

The setup that was quietly making things worse

The default Dependabot setup, one PR per dependency at whatever rhythm the ecosystem publishes, is fine when your repo has ten dependencies. On a service with a few hundred transitive updates a week, it becomes a queue nobody triages. When triage stops, the PRs sit. When the PRs sit, the CI cost sits with them. And somewhere in that pile is the security update that actually matters, wearing the same title format as everything else.

The guide names the pattern I was living in without knowing it had one. Dependabot as noise, instead of Dependabot as a supply-chain control. Muting it feels wrong because you know that one PR in the middle is a real fix. Reviewing all of it feels wrong because it is your whole afternoon.

Three levers, in the order I would set them

Group the version updates into one PR. Add a groups block to .github/dependabot.yml. In its simplest form:

groups:
  monthly-batch:
    patterns:
      - "*"

The "*" pattern bundles every version update the bot would otherwise open into a single pull request. Reviewing forty updates in one thread feels different from reviewing forty inboxes. You get one CI run, one merge, one revert if it breaks. This is the change that made me stop scrolling past chore(deps): titles.

Slow the cadence. The default schedule.interval on most examples is daily. If you rarely ship a dependency bump in the middle of a working day, switch to weekly or monthly:

schedule:
  interval: "monthly"

The rhythm shift is the point. Instead of "whenever anything changes", version updates arrive on a scheduled window you can plan around. Combined with grouping, that means one PR, once a month, for the whole set of version bumps on that ecosystem. Nothing glamorous about it. It is what makes the queue tractable again.

Do not touch security updates. This is the part I got wrong the first time. When you set groups and a schedule, you might expect the same rules to apply to security fixes. They don't. The GitHub post is explicit that the groups and schedule you configure here shape version updates, and security updates keep coming through independently, as soon as a fix for a disclosed vulnerability is available. That separation is why this config is safe to ship. You are slowing down the noisy channel without slowing down the channel that matters.

Alongside these three levers, the post also nods at the default cooldown on version-update PRs that GitHub added earlier in the year: a new release has to sit on its registry for a few days before Dependabot will open a PR against it. Between groups, cadence and cooldown, the version-update PR that finally lands has been on the registry for a while and arrives on a schedule you set. It stops competing with the security fix for your attention, which is the point.

Rough edges worth naming

The wildcard "*" group is a great starting point and a bad ending point. On a big service, one giant PR of every ecosystem update lands in a single CI run, and if any one dep breaks the build, the whole batch is stuck behind it. After a month of the "one big PR" version, split the group by ecosystem, or by risk (production deps vs dev deps). The post presents groups as a general primitive; picking a division that maps to how your team reviews is on you.

There is also a governance angle. Slowing the cadence to monthly shifts responsibility onto whoever owns the merge window. Miss the monthly PR and you have a full month of drift, which is not the story you want to tell in an audit conversation later. Put the merge on a named person's calendar, and put a fallback owner behind them.

What I am watching next

I want the group-and-cadence controls at the org level, the way rulesets already are. Editing dependabot.yml across a fleet still means a script or a copy-paste tour of every repo, and the recent rulesets work has already shown me how much friction goes away when a policy has an org home. Until then, this post is the memo GitHub effectively wrote for me about a config I have been meaning to ship for a long time, and I do not have an excuse to keep it in the "later" folder anymore.