GitHub announced on November 10, 2026 that, starting December 8, it will turn off Dependabot alerts on most repositories with no activity in the past year. Existing alerts are archived, not deleted, and can be restored. GitHub's stated reason is the fast growth in vulnerability discovery and alert volume, which it wants to keep fast for repositories under active development.
A repository without commits can still be running a production system. A company website, an internal API or a plugin delivered to a client can go a year without a commit and stay online with the same dependencies. A vulnerability published in those dependencies after that point no longer shows up as an alert.
What counts as activity
According to the changelog, only three events restart the one-year clock:
- a push to any branch or tag;
- creating the repository;
- turning on Dependabot alerts.
Opening an issue, commenting or running a workflow is not on the list. Any push turns alerts back on automatically, and they can also be re-enabled in the repository settings. Either way, GitHub restores the archived alerts and the clock starts over.
The change applies to all plans on github.com and to GitHub Enterprise Cloud with data residency. GitHub Enterprise Server is not affected.
Who loses alerts without noticing
The most exposed cases are code that is finished and still running: agency projects delivered and maintained on demand, stable internal libraries, WordPress or Laravel sites that only change when someone asks. This is the stage where responsibility for the system is often already unclear, the subject of who looks after the system once the project ends, and now the system also loses an automatic warning.
Organizations that already enforce a security configuration with Dependabot alerts enabled are not affected. Neither are enterprises whose policy prevents repository administrators from enabling or disabling alerts.
What to do before December 8
First, list the repositories with no push in twelve months and separate the ones that back something in production. That match depends on your own inventory, because GitHub does not know what is live.
For the ones that need to stay monitored, the route GitHub itself points to is the formal exemption: an organization security configuration, enforced, with Dependabot alerts enabled, or the equivalent enterprise policy. An empty push or turning alerts back on by hand also works, but only for another year, and it depends on someone remembering. In my view, that is only a stopgap until the organization configuration is in place.
For code that really has been abandoned, the change may be acceptable. In that case, archive the repository and record that nobody is tracking that code's dependencies anymore.
What the announcement does not say
The text only mentions alerts. It does not say whether Dependabot security updates, which open fix pull requests based on alerts, also stop, or whether there will be an email or in-app notice before each repository is paused. It also does not mention an API or dashboard filter to list the affected repositories. The announcement's "most repositories" suggests there may be other exceptions beyond the two it describes. Until GitHub gives more detail, the safe assumption is that an inactive repository with no exemption configured stops receiving alerts on December 8.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
