Today, only the security alerts with runtime scope and a high or critical severity; everything else can wait for a fixed slot in the week. Development dependencies and grouped version updates are real work, but they rarely change what your users run.
Runtime or development scope?
Runtime first, because that is the code your application runs in production. GitHub’s documentation puts it in two sentences: “Runtime dependencies are used by an application in production”, while “development dependencies are only used during development, testing, or build processes” (GitHub Docs, prioritizing Dependabot alerts, checked 9 October 2026). The same page suggests the order: severity first, then the likelihood of exploitation (EPSS), then scope and whether the dependency is direct.
Across our own repositories, Dependabot opened 50 alerts between 25 September and 9 October 2026 (counted on 9 October 2026 through the GitHub API, open, fixed and dismissed together): 18 with runtime scope and 32 with development scope. Among the 18 runtime alerts, 14 were high; among the 32 development alerts, 12 were high. Filtering with scope:runtime and severity:high would have left 14 of 50 for the same day.
Scope is only as good as its detection. GitHub introduced the filter for RubyGems, npm, Composer, Maven, Poetry, pip, NuGet in part and Cargo; Yarn and Go modules count everything as runtime (GitHub Changelog, 23 June 2022, checked 9 October 2026). In those ecosystems, runtime means “not classified”, not “in production”.
What do groups change?
Groups change how many pull requests arrive, not which alerts exist. “A Dependabot group bundles multiple dependency updates into one pull request”, writes the GitHub Blog, and the groups and the schedule “shape your version updates, not your security fixes” (GitHub Blog, Tame Dependabot, 29 July 2026, checked 9 October 2026).
For a solo developer that is the useful split: version updates in one grouped pull request per week or month, security updates as they come. In gitpuls, the grouped updates sit at the end of each Dependabot entry for that reason. On 9 October 2026 at 18:48, our gitpuls database listed 0 open alerts across 18 checked repositories, so 0 runtime and 0 development; the 50 alerts above had all been fixed or dismissed by then.
How old may an update get?
As old as the slot you set for it, as long as it is not a runtime alert with a high severity. Of our 39 fixed alerts, the runtime ones were closed after 0.9 days on average and at most 2 days, the development ones after 0.6 days on average and at most 5 days (alert opened to fixed, counted on 9 October 2026).
The development alerts were not left lying even though there were more of them. A rule that works for us: runtime and high on the same day, everything else within the week, and an alert that is older than a week gets a decision, either an update or a dismissal with a reason.
How this text was written
This article was drafted with an AI assistant from our own measurements and the sources linked above, which were checked on 9 October 2026. The numbers come from the method page; nothing was estimated.