GitHub’s changelog, published 10 November 2026, says that from 8 December 2026 Dependabot alerts will be turned off on most repositories with no activity in the past year. Existing alerts are archived, not deleted.
What counts as activity
Pushing to any branch or tag, creating the repository, or turning on Dependabot alerts. Nothing else. A repository that is quietly running a live product but has not been touched for twelve months looks, to GitHub, the same as an abandoned one.
How to keep or restore alerts
Any push to the repository switches alerts back on and restores the archived ones. You can also re-enable them in the repository settings. Either way the one-year clock restarts. Repositories covered by an enforced organisation security configuration that enables Dependabot alerts, and enterprises whose policy stops administrators changing the setting, are exempt. The page does not describe a per-repository opt-out. It applies to github.com plans and Enterprise Cloud with data residency, not Enterprise Server.
Why this matters to buyers
Plenty of business software is built once and then left running: an internal tool, a booking app’s backend, a client portal. Those are exactly the repositories that go a year without a commit. After 8 December, the warning that a library in that code has a known vulnerability may simply stop arriving, and nobody will notice the silence.
So what
Ask whoever built your software two questions: which repositories have had no activity for a year, and who is watching security alerts on them once GitHub stops sending them? An agreed maintenance retainer answers both. Our custom software development work includes a handover plan for exactly this, and healthcare software development adds the stricter patching expectations that sector carries. If you have code nobody is watching, start a project and we will review it.