cooldown should filter versions before checking if it's a valid dependency update #14234
Description
Is there an existing issue for this?
- I have searched the existing issues
Package ecosystem
github-actions
Package manager version
No response
Language version
No response
Manifest location and content before the Dependabot update
In many repos we have dependabot scheduled to run weekly with cooldown enabled (7 days).
For any packages that are released regularly (e.g. ruby/setup-ruby) results in dependabot filtering out all new versions, thereby exceeding the cooldown duration.
An example that I saw earlier this week:
Bumps ruby/setup-ruby from 1.268.0 to 1.288.0.
| Version | Release Date |
|---|---|
| 1.268 | 2025/11/17 |
| 1.269 | 2025/12/05 |
| 1.270 | 2025/12/13 |
| 1.271 | 2025/12/17 |
| 1.272 | 2025/12/18 |
| 1.273 | 2025/12/18 |
| 1.274 | 2025/12/18 |
| 1.275 | 2025/12/20 |
| 1.276 | 2025/12/25 |
| 1.277 | 2025/12/30 |
| 1.278 | 2025/12/31 |
| 1.279 | 2026/01/05 |
| 1.280 | 2026/01/07 |
| 1.281 | 2026/01/10 |
| 1.282 | 2026/01/13 |
| 1.283 | 2026/01/14 |
| 1.284 | 2026/01/18 |
| 1.285 | 2026/01/20 |
| 1.286 | 2026/01/21 |
| 1.287 | 2026/01/30 |
| 1.288 | 2026/02/03 |
Dependabot has been successfully running for this repo each week.
An example dependabot run log:
updater | 2026/01/19 02:12:18 INFO <job_1212489264> Checking if ruby/setup-ruby 1.268.0 needs updating
proxy | 2026/01/19 02:12:18 [020] GET https://github.com/ruby/setup-ruby.git/info/refs?service=git-upload-pack
proxy | 2026/01/19 02:12:18 [020] 200 https://github.com/ruby/setup-ruby.git/info/refs?service=git-upload-pack (cached)
proxy | 2026/01/19 02:12:19 [024] GET [https://api.github.com:443/repos/ruby/setup-ruby/releases?per_page=100](https://api.github.com/repos/ruby/setup-ruby/releases?per_page=100)
2026/01/19 02:12:19 [024] * authenticating github api request with token for api.github.com
proxy | 2026/01/19 02:12:19 [024] 200 [https://api.github.com:443/repos/ruby/setup-ruby/releases?per_page=100](https://api.github.com/repos/ruby/setup-ruby/releases?per_page=100)
updater | 2026/01/19 02:12:19 INFO <job_1212489264> Available release version/ref is 1.284.0
updater | 2026/01/19 02:12:19 INFO <job_1212489264> Initializing cooldown filter
Since the filtering occurs after the next version candidate is determined, a dependency bump is not proposed.
Dependabot doesn't fall back to any of the intervening previous versions that would constitute a dependency update while still honouring the cooldown period.
This has been a recurring issue that we've seen across many repos.
I think this may occur with bundler as well, but I don't have an example to hand to verify this.
dependabot.yml content
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
day: "monday"
time: "02:00"
cooldown:
default-days: 7
open-pull-requests-limit: 99
Updated dependency
No response
What you expected to see, versus what you actually saw
Expectation
Any dependency updates that fulfil the criteria of:
- is a version update
- respects the cooldown duration
Dependabot should propose as a valid dependency bump.
Actuality
Dependabot prevented a dependency from updating for over 3 months due to a cooldown period of 7 days.
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response