Dependabot PRs should include cooldown settings in the PR descriptions

[jasonkarns]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Other

Body

Dependabot cooldown is a useful option to help make dep updates secure. But at the moment a dependabot PR is being reviewed or approved, there is no context regarding the age of the dependency, or whether cooldown was in effect at the time the PR was introduced.

Dependabot PRs should include age information in the PR description (along with the current release information), and optionally include whether cooldown was in effect. This information is useful for conducting reviews.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[prashantkoirala465]

I like this idea.

When I'm reviewing a Dependabot PR, I usually want more context than just "a new version is available." Knowing when that version was released can influence how comfortable I am merging it.

For example, if a release is only a few hours old, I might prefer to let it sit for a few days in case regressions are discovered. If it's already been out for a couple of weeks, I'm generally more confident moving forward.

Including something like:

• Release date
• Age of the release (e.g. "Released 14 days ago")
• Whether the PR respected the configured cooldown

would make that context immediately available without reviewers having to leave GitHub and look it up themselves.

Even if it were just an optional section in the PR description, I think it would make reviewing Dependabot updates a bit smoother.

[mohammadrezwankhan]

Agreed — release age and the cooldown decision are exactly the review context that is missing today.

A current workaround is to configure cooldown in each relevant updates block:

version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule: { interval: daily }
    cooldown:
      default-days: 5
      semver-major-days: 30
      semver-minor-days: 7
      semver-patch-days: 3

The current cooldown reference says this applies to version updates, not security updates; the default is 3 days when no custom cooldown is set; configured values are 1–90 days; include/exclude support up to 150 entries; and exclude wins when a dependency matches both. The worked example is useful for testing the behavior.

For the PR body, I would add one row per dependency (including grouped PRs):

• release URL and published timestamp
• age at PR creation (for example, Released 14 days ago)
• configured cooldown, calculated eligible-at time, and whether the update is a security update (not applicable)
• the dependabot.yml path/commit used for the calculation

The time calculation should be labeled derived, not presented as an internal scheduler verdict: package-manager metadata, grouped updates, and a later config edit can otherwise make the result look authoritative when it is only an audit snapshot. A small Action can provide that snapshot today by reading Dependabot metadata plus the registry/release timestamp and posting a check-run or comment. A native generated block plus machine-readable fields would make the context durable and refresh it when the PR is regenerated.