{"id":4685,"date":"2026-07-29T16:54:07","date_gmt":"2026-07-29T16:54:07","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/29\/tame-dependabot-group-your-updates-slow-the-cadence-keep-security-fast\/"},"modified":"2026-07-29T16:54:07","modified_gmt":"2026-07-29T16:54:07","slug":"tame-dependabot-group-your-updates-slow-the-cadence-keep-security-fast","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/29\/tame-dependabot-group-your-updates-slow-the-cadence-keep-security-fast\/","title":{"rendered":"Tame Dependabot: Group your updates, slow the cadence, keep security fast"},"content":{"rendered":"<p class=\"wp-block-paragraph\">If you maintain an active repository, you know the feeling. You open your notifications on a Monday morning and there they are: five, 10, sometimes a dozen Dependabot pull requests, each bumping a single dependency by a single patch version. Individually, every one of them is helpful. Collectively, they\u2019re noise. And noise is how important updates get ignored.<\/p>\n<p class=\"wp-block-paragraph\">We looked at <a href=\"https:\/\/github.com\/microsoft\/gctoolkit\">Microsoft\u2019s GCToolkit<\/a>, an open source Java library for analyzing garbage collection logs. As of July 2026, a <code>git log<\/code> of the repository showed that <strong>92 of its 578 commits, roughly one in six, were Dependabot version bumps<\/strong>, with 61 in the previous 12 months alone, sometimes several in a single day. That\u2019s a lot of review, merge, and CI cycles spent on routine maintenance.<\/p>\n<p class=\"wp-block-paragraph\">The good news: Dependabot already ships with the features to fix this. In <a href=\"https:\/\/github.com\/microsoft\/gctoolkit\/pull\/572\">a recent pull request<\/a>, the project changed its <code>dependabot.yml<\/code> in three small but meaningful ways, turning a daily drip of single-dependency pull requests into a predictable, grouped, monthly batch per ecosystem. Here\u2019s what changed, why it works, and how to apply the same pattern to your own repositories, following the GCToolkit example.<\/p>\n<h2 class=\"wp-block-heading\">The problem: Good defaults, wrong cadence<\/h2>\n<p class=\"wp-block-paragraph\">Here\u2019s what GCToolkit\u2019s configuration looked like before:<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code\"><code>version: 2\nupdates:\n- package-ecosystem: github-actions\n  directory: \"\/\"\n  schedule:\n    interval: daily\n  open-pull-requests-limit: 10<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">This is a common starting point, but the <code>daily<\/code> interval here was a deliberate choice, not a default: <code>schedule.interval<\/code> is required, and GitHub\u2019s <a href=\"https:\/\/docs.github.com\/en\/code-security\/dependabot\/dependabot-version-updates\/configuring-dependabot-version-updates\">suggested starter template<\/a> uses <code>weekly<\/code>. Two things make this configuration noisy:<\/p>\n<ul class=\"wp-block-list\">\n<li><strong><code>interval: daily<\/code><\/strong> tells Dependabot to check for updates every weekday (Monday through Friday). For a repository that references a handful of GitHub Actions, that can mean new pull requests landing on any weekday.<\/li>\n<li><strong>No grouping<\/strong> means every dependency gets its own pull request. Ten available updates equals 10 pull requests, 10 CI runs, and 10 review notifications.<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">The <code>open-pull-requests-limit: 10<\/code> line is a symptom, not a cure: it caps the flood at 10 open pull requests, but it doesn\u2019t stop the flood.<\/p>\n<h2 class=\"wp-block-heading\">The fix: Three changes that compound<\/h2>\n<p class=\"wp-block-paragraph\">Here\u2019s the configuration after the change:<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code\"><code>version: 2\nupdates:\n  - package-ecosystem: \"github-actions\"\n    directory: \"\/\"\n    schedule:\n      interval: \"monthly\"\n    groups:\n      monthly-batch:\n        patterns:\n          - \"*\"\n\n  - package-ecosystem: \"maven\"\n    directory: \"\/\"\n    schedule:\n      interval: \"monthly\"\n    groups:\n      monthly-batch:\n        patterns:\n          - \"*\"<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">Three things are happening here, and they build on each other.<\/p>\n<h3 class=\"wp-block-heading\">1. Group everything into a single pull request<\/h3>\n<p class=\"wp-block-paragraph\">The <code>groups<\/code> block is the heart of this change:<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code\"><code>groups:\n  monthly-batch:\n    patterns:\n      - \"*\"<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">A <a href=\"https:\/\/docs.github.com\/en\/code-security\/dependabot\/working-with-dependabot\/optimizing-pr-creation-version-updates\">Dependabot group<\/a> bundles multiple dependency updates into one pull request. The name (<code>monthly-batch<\/code>) is yours to choose. It shows up in the pull request title and branch name. The <code>patterns<\/code> list decides which dependencies belong to the group, and <code>\"*\"<\/code> is a wildcard that matches all of them.<\/p>\n<p class=\"wp-block-paragraph\">So instead of 10 pull requests, you get one pull request titled something like <em>\u201cBump the monthly-batch group with 10 updates.\u201d<\/em> One branch. One CI run. One review. If the whole batch is green, you merge once and you\u2019re done. If something breaks, it\u2019s contained in a single, reviewable place.<\/p>\n<p class=\"wp-block-paragraph\">For larger projects, you don\u2019t have to lump everything together. You can define multiple named groups with more specific patterns. For example, you could keep all your testing libraries in one group and your production dependencies in another, so related updates travel together and unrelated ones stay separate.<\/p>\n<p class=\"wp-block-paragraph\">Grouping keeps getting more capable, too. In a <a href=\"https:\/\/github.blog\/changelog\/2026-02-24-dependabot-can-group-updates-by-dependency-name-across-multiple-directories\/\">February 2026 update<\/a>, Dependabot gained the ability to group updates for the <em>same<\/em> dependency <strong>across multiple directories<\/strong> into a single pull request. That\u2019s aimed squarely at monorepos: if one library is pinned in a dozen services, a single bump used to open a dozen near-identical pull requests, one per directory. Now you can point the <code>directories<\/code> key (note the plural) at a list of paths, or a glob like <code>\/apps\/*<\/code>, and let your group collapse all of them into one:<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code\"><code>- package-ecosystem: \"npm\"\n  directories:\n    - \"\/apps\/*\"\n  schedule:\n    interval: \"monthly\"\n  groups:\n    monthly-batch:\n      group-by: dependency-name\n      patterns:Expand comment\n        - \"*\"<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">That\u2019s the same <code>monthly-batch<\/code> group as before, now spanning every service in the repository instead of a single directory. For the full set of options, see the <a href=\"https:\/\/docs.github.com\/en\/code-security\/reference\/supply-chain-security\/dependabot-options-reference\">Dependabot options reference<\/a>.<\/p>\n<h3 class=\"wp-block-heading\">2. Slow the cadence from daily to monthly<\/h3>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code\"><code>schedule:\n  interval: \"monthly\"<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">Switching from <code>daily<\/code> to <code>monthly<\/code> changes the rhythm from \u201cwhenever anything changes\u201d to \u201conce, on a schedule you can plan around.\u201d Combined with grouping, this is the real noise reduction: Dependabot now opens <strong>one<\/strong> batched pull request per ecosystem, per month, instead of a steady trickle all month long.<\/p>\n<p class=\"wp-block-paragraph\">Monthly is the right call for a mature library where dependencies are stable and updates are rarely urgent. If you want something in between, <code>weekly<\/code> is also available, and you can pin the exact day and time with <code>schedule.day<\/code> and <code>schedule.time<\/code>.<\/p>\n<h3 class=\"wp-block-heading\">3. Cover every ecosystem you actually use<\/h3>\n<p class=\"wp-block-paragraph\">The original config only requested version updates for <code>github-actions<\/code>. But GCToolkit is a Java project built with Maven, so its application dependencies weren\u2019t receiving Dependabot version updates. The updated config adds a second <code>updates<\/code> entry:<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code\"><code>- package-ecosystem: \"maven\"\n  directory: \"\/\"<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">This is an easy one to miss. Reducing noise is only half the win; the other half is making sure Dependabot is watching the dependencies that matter most. Each ecosystem gets its own schedule and its own group, so your Actions updates and your Maven updates arrive as two clean, separate batches.<\/p>\n<h2 class=\"wp-block-heading\">But what about security updates?<\/h2>\n<p class=\"wp-block-paragraph\">This is the question every maintainer should ask before slowing anything down, and it\u2019s where the design really shines: <strong>by default, the groups and schedule you set here shape your version updates, not your security fixes.<\/strong><\/p>\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/docs.github.com\/code-security\/dependabot\/dependabot-security-updates\/about-dependabot-security-updates\">Dependabot security updates<\/a> are raised as soon as a vulnerability with a fix is disclosed, independent of your <code>schedule<\/code> and separate from your version-update groups. So a monthly batch cadence for routine bumps doesn\u2019t delay a critical patch. (You <em>can<\/em> batch security fixes on purpose with a group scoped to <code>applies-to: security-updates<\/code>, but even then they\u2019re triggered by disclosures, not by your version-update schedule.)<\/p>\n<p class=\"wp-block-paragraph\">One caveat: this safety net only exists if Dependabot security updates are actually turned on for the repository, which also requires the dependency graph and Dependabot alerts to be enabled. Confirm those are on before you rely on a slower version-update cadence. Do that, and you get the best of both worlds: quiet, predictable maintenance for the routine stuff, and immediate action when a real vulnerability lands.<\/p>\n<p class=\"wp-block-paragraph\">That separation is what makes \u201cslow down Dependabot\u201d a safe recommendation rather than a risky one.<\/p>\n<h2 class=\"wp-block-heading\">A new safety net: default package cooldown<\/h2>\n<p class=\"wp-block-paragraph\">There\u2019s one more piece of noise reduction that landed recently, and it happens automatically. <a href=\"https:\/\/github.blog\/security\/supply-chain-security\/the-case-for-a-cooldown-why-dependabot-now-waits-before-issuing-version-updates\/\">Dependabot now waits<\/a> until a new release has been on its registry for at least <strong>three days<\/strong> before opening a version-update pull request. This <em>cooldown<\/em> is the default and requires no configuration.<\/p>\n<p class=\"wp-block-paragraph\">Why wait? A brand-new release is one of the most common entry points for a supply chain attack. A compromised or simply broken version can reach your dependency updates before maintainers and the wider community have caught the problem. A short delay gives that signal time to surface, so you\u2019re far less likely to merge a bad release the moment it ships.<\/p>\n<p class=\"wp-block-paragraph\">Two things worth knowing:<\/p>\n<ul class=\"wp-block-list\">\n<li><strong>It only applies to version updates.<\/strong> Security updates still open immediately, so critical fixes are never held back by the cooldown.<\/li>\n<li><strong>You stay in control.<\/strong> Use the <a href=\"https:\/\/docs.github.com\/code-security\/reference\/supply-chain-security\/dependabot-options-reference#cooldown-\"><code>cooldown<\/code><\/a> option in your <code>.github\/dependabot.yml<\/code> to widen or shorten the window, tune it per semantic-versioning level, or opt out entirely:<\/li>\n<\/ul>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code\"><code>- package-ecosystem: \"maven\"\n  directory: \"\/\"\n  schedule:\n    interval: \"monthly\"\n  cooldown:\n    default-days: 7\n  groups:\n    monthly-batch:\n      patterns:\n        - \"*\"<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">Pair cooldown with grouping and a monthly cadence and the effect compounds: fewer pull requests, and the ones you do get have had a few days to prove they\u2019re safe to merge.<\/p>\n<h2 class=\"wp-block-heading\">How to apply this to your own repositories<\/h2>\n<p class=\"wp-block-paragraph\">You can adopt this pattern in a few minutes:<\/p>\n<ol class=\"wp-block-list\">\n<li>Open (or create) <code>.github\/dependabot.yml<\/code> in the default branch of your repository.<\/li>\n<li>For each <code>package-ecosystem<\/code> you depend on, set <code>schedule.interval<\/code> to <code>weekly<\/code> or <code>monthly<\/code>.<\/li>\n<li>Add a <code>groups<\/code> block with a single wildcard group (<code>patterns: [\"*\"]<\/code>) to batch updates into one pull request per ecosystem.<\/li>\n<li>Make sure every ecosystem you actually ship with is listed: not just <code>github-actions<\/code>, but <code>maven<\/code>, <code>npm<\/code>, <code>pip<\/code>, <code>gomod<\/code>, <code>docker<\/code>, and so on.<\/li>\n<li>Commit, and let the next scheduled run produce a single, grouped pull request.<\/li>\n<\/ol>\n<p class=\"wp-block-paragraph\">A few tips as you tune it:<\/p>\n<ul class=\"wp-block-list\">\n<li><strong>Start broad, then split.<\/strong> A single wildcard group is the simplest starting point. If you later find you want, say, patch-level and major-version updates handled differently, break the wildcard into more targeted named groups.<\/li>\n<li><strong>Don\u2019t fold security fixes into this cadence.<\/strong> Dependabot security updates are triggered by vulnerability disclosures, not your version-update schedule, so a monthly cadence never delays them. You can even group them with <code>applies-to: security-updates<\/code> without slowing them down.<\/li>\n<li><strong>Lean on cooldown.<\/strong> The three-day default already shields you from brand-new bad releases; bump <code>cooldown.default-days<\/code> higher if you want an even wider safety margin on version updates.<\/li>\n<li><strong>Right-size the interval.<\/strong> Fast-moving apps may prefer <code>weekly<\/code>; stable libraries do fine on <code>monthly<\/code>.<\/li>\n<li><strong>Consolidate monorepo directories.<\/strong> If the same dependency lives in many directories, list them under <code>directories<\/code> and set <code>group-by: dependency-name<\/code> in the group so a single bump produces one pull request instead of one per directory.<\/li>\n<\/ul>\n<h2 class=\"wp-block-heading\">The takeaway<\/h2>\n<p class=\"wp-block-paragraph\">Dependency updates are one of those chores that\u2019s easy to automate and then easy to start ignoring, which defeats the purpose. The fix isn\u2019t to turn Dependabot off or to merge pull requests without looking. It\u2019s to shape its output so that the routine work is quiet and batched, and the urgent work still cuts through.<\/p>\n<p class=\"wp-block-paragraph\">GCToolkit did it with about a dozen lines of YAML: group everything, slow the cadence to monthly, and make sure every ecosystem is covered. Add the new default cooldown on top, and even that monthly batch has had a few days to prove itself before it reaches you. The result is fewer pull requests, fewer CI runs, and, most importantly, a review queue where the updates that matter don\u2019t get lost in the ones that don\u2019t.<\/p>\n<p class=\"wp-block-paragraph\"><em>Further reading: once the routine pull request noise is under control, the harder question is which security alerts to fix first. Our earlier post, <a href=\"https:\/\/github.blog\/security\/application-security\/cutting-through-the-noise-how-to-prioritize-dependabot-alerts\/\">Cutting through the noise: How to prioritize Dependabot alerts<\/a>, walks through using EPSS scores and repository properties to turn an overwhelming alert list into a clear, risk-ranked queue.<\/em><\/p>\n<div class=\"wp-block-group post-content-cta has-global-padding is-layout-constrained wp-block-group-is-layout-constrained\">\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/docs.github.com\/code-security\/dependabot\/dependabot-version-updates\/configuring-dependabot-version-updates\">Configure your own Dependabot updates &gt;<\/a><\/p>\n<\/div>\n<p>The post <a href=\"https:\/\/github.blog\/security\/supply-chain-security\/tame-dependabot-group-your-updates-slow-the-cadence-keep-security-fast\/\">Tame Dependabot: Group your updates, slow the cadence, keep security fast<\/a> appeared first on <a href=\"https:\/\/github.blog\/\">The GitHub Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"<p>If you maintain an active repository, you know the feeling. You open your notifications on a Monday morning and there [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":94,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[8],"tags":[],"class_list":["post-4685","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-github-engineering"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4685","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=4685"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4685\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/94"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=4685"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=4685"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=4685"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}