GitHub's auto-update tool now waits three days before flagging new package versions

Dependabot, GitHub's automated tool for flagging new versions of the third-party code a project depends on, will now wait three days after a new release hits its registry before opening a pull request. The hold is the new default, announced on 14 July 2026 in the GitHub Changelog. Projects that have not set their own cooldown configuration inherit the wait; projects that care about a specific ecosystem can shorten or override it through the options reference.

Before 14 July, the same three-day cooldown existed as a per-repository configuration, set through the cooldown option in a project's Dependabot configuration file. A team that cared about supply-chain hygiene could turn it on for their own repos. The default-shift is what makes this news: every project that uses Dependabot version updates and has not already overridden the setting now inherits the wait, including the long tail of repos that have never thought about supply-chain security.

The mechanism is platform-imposed friction in an auto-update loop that historically traded pause-time for speed. Dependabot watches a project's dependency manifest, compares it to the latest published versions, and opens a pull request that bumps the pinned version. For years, that loop ran at registry speed: a maintainer could publish a release, and within minutes Dependabot would start proposing it across every repo that had opted in. The new default inserts a three-day hold between "package published" and "pull request opened." Dependabot's version-updates concept page places the tool inside GitHub's broader supply-chain security product line, alongside code scanning and secret scanning.

The argument for the default is the case the changelog implicitly makes: a newly published package version is the artifact most likely to be broken, malicious, or yanked, and an auto-update bot that opens a pull request the moment the version lands is a force multiplier for whichever of those three turns out to be true. A three-day hold does not eliminate that risk; it pushes the bot's reaction behind the period in which a maintainer is most likely to discover and respond to a bad release.

The strongest counterargument is the one a careful reader will reach on their own: the cooldown was already available as opt-in, so the default shift is incremental. That framing is wrong about who moves. The opt-in version put friction on "projects that already cared about supply-chain hygiene," which on a platform this large is a minority. The default version puts friction on every project, including the repos that have never thought about it. The friction moved; it did not just appear.

npm, PyPI, and the major Linux distributions have all spent the last two years layering delay and review steps into their publish paths after high-profile supply-chain incidents. Dependabot's default cooldown is GitHub applying the same default-friction logic to the read side of the same problem. The slow-down has moved from "publishing a bad package" to "the auto-update bot picking one up."

Simon Willison's Weblog picked up the changelog item the same day under the title "Quoting GitHub Changeling," a wordplay on changelog and changeling, and added no new facts beyond the GitHub text. The post is useful as a marker that the change was visible to a developer-tools audience immediately, and as a reminder that the original-signal anchor is the GitHub Changelog entry itself.

The watch item for the next few weeks is whether the default starts to bend. Project owners who hit the three-day wait on a high-velocity dependency can shorten it per ecosystem, and the option is documented. The bigger question is whether the cooldown becomes a quiet industry default the way two-factor prompts and signed commits have, or stays a GitHub-specific setting that other auto-update systems do not copy.