Dependabot ages version updates before opening pull requests

The release enters the queue

Take an npm service with two dependencies: the public package public-parser and a team-maintained package named @acme/incident-client. At 08:00 UTC on Monday, each publishes a routine update. Dependabot does not respond to that registry event by opening a version-update pull request. For a daily configuration, it checks on the configured schedule and then applies a release-age cooldown. A release younger than the applicable delay is skipped. GitHub now applies a three-day default to version updates even when the configuration has no cooldown block.¹

Engineers were already choosing longer waits before that platform default arrived. A 2026 study began with the 10,000 most-starred GitHub repositories and retained 1,462 active repositories with a Dependabot configuration. Of those, 135 had adopted cooldown by April 30, 2026. Among 244 retained repository-ecosystem configurations that explicitly set a general delay, 157 chose seven days.² The study measured configuration practice. It did not test whether a cooldown prevented an attack or establish seven days as an optimum. Gregor Ehrensperger recommends seven days but describes that interval as a judgment call. Compared with GitHub's three-day default, his choice also postpones legitimate version-update fixes and features by four more days.³

The configuration changes the wait

The service team wants ordinary patches to sit for three days, major and minor releases to sit for seven, and its incident client to remain available at the next scheduled check. Dependabot security updates are separately enabled in the repository settings. Its complete .github/dependabot.yml is:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
      time: "09:00"
    cooldown:
      default-days: 7
      semver-patch-days: 3
      include:
        - "*"
      exclude:
        - "@acme/incident-client"

The patch-specific value overrides default-days for patch releases. Because the major- and minor-specific keys are absent, those updates fall back to seven days. The wildcard puts every dependency into the cooldown set, then the exact exclude match wins for the incident client.¹

On September 27, 2026, this YAML parsed successfully and produced zero validation errors against the public SchemaStore Dependabot 2.0 JSON Schema.⁴ That was a syntax and schema check, not a run against hosted Dependabot. The public schema is also an imperfect proxy for the service. GitHub's tutorial documents 1–90 days and as many as 150 entries in each package list. The schema caps those lists at 100 and permits zero only for semver-patch-days.⁵ The example stays inside both sets of bounds.

Three releases leave by different paths

The same configuration sends three releases through different gates. The times below are documentation-backed analysis, not output from a test repository. GitHub does not promise exact service latency or say that every eligible release appears on the first run after its delay.

Four controls are acting at different points. The schedule decides when Dependabot looks. Cooldown decides which release ages are eligible on that run. A groups rule, absent here, would decide which eligible updates share a pull request. The open-PR limit decides whether another version-update PR may open; its default is five, and security PRs neither count toward nor obey that limit.¹

The observation window needs an exit

Cooldown delays Dependabot's proposal of a version update. It does not stop a direct install, a manual lockfile refresh, or another bot from adopting a fresh release, and it does not decide whether an eligible Dependabot pull request is merged. The security bypass also depends on an alert for a dependency on the default branch and a fix that Dependabot can construct. GitHub documents a Gradle case in which an uploaded transitive dependency can produce an alert but Dependabot cannot locate it in the repository to create a security PR.⁸

The repository's operating rule should cover all three paths. Routine releases wait for the configured observation window. Alerts enter an enabled security-update path with human or automated escalation if no PR appears. Excluded packages move on the next scheduled version run only when the team has chosen to trust that faster route. Dependabot enforces the release-age gate. The repository decides when to merge routine updates and how to respond when an urgent security PR does not appear.