GitHub says it will begin pausing Dependabot alerts on most repositories with no recorded activity in the previous year on December 8, 2026. The change is about the alert feature: existing alerts will be archived, not deleted, and GitHub says a repository can restore them. Maintainers of older projects should check the activity rule and exemptions before assuming alerts will stay enabled or that their findings have been erased.
What does GitHub count as activity?
GitHub lists three qualifying events: creating the repository, pushing to any branch or tag, and turning on Dependabot alerts. A push does not need to land on the default branch to count under the published rule. The announcement does not list other common maintenance actions, such as opening an issue or editing repository settings, as activity. Teams with repositories they intend to keep dormant should use the stated rule rather than relying on general interaction as a reset.
What happens to the existing alerts?
For a repository that meets the inactivity condition and is not exempt, GitHub says Dependabot alerts will be turned off and the existing alerts archived. It says any subsequent push automatically turns the alerts back on; an administrator can also enable them from the repository settings. In either case, GitHub says it restores the archived alerts and starts a new one-year activity period. The announcement describes archived alerts as recoverable, not deleted.
This is a change to Dependabot alerts, which notify maintainers when GitHub identifies a vulnerable dependency. It should not be read as a statement that GitHub deletes the repository, its dependency files or source code. The practical consequence is narrower: a dormant repository may stop receiving this class of alert until someone restores the setting, so an old project that still matters needs an owner to notice and act.
Which repositories are exempt?
GitHub lists two policy-based exceptions. Alerts remain on when an enforced security configuration enables Dependabot alerts. GitHub also skips repositories in enterprises whose Dependabot alerts policy does not allow repository administrators to enable or disable the feature. The exception depends on organization or enterprise policy, so repository administrators may need to ask an owner which configuration applies.
The change covers all plans on github.com and GitHub Enterprise Cloud with data residency. GitHub says alerts archived for data-residency customers remain stored in the same region as the rest of the enterprise data. GitHub Enterprise Server is excluded. The announcement does not limit the change to a particular paid Copilot or security tier.
What should maintainers do before December 8?
Teams can identify repositories that have been untouched for a year, decide whether Dependabot alerts should remain active, and verify whether an enforced security configuration or enterprise policy already protects them. If a dormant repository still needs monitoring, a push or re-enabling alerts in repository settings will restore the archived alerts and reset the activity clock. GitHub's documentation provides the repository-level settings path for users with permission to manage the feature.
How to test an AI-built app before inviting users
For makers, the announcement is a reminder that security checks depend on both tooling and ownership. A repository can be intentionally quiet yet still contain software worth maintaining. The new rule offers a clear recovery path, but it also makes it useful to review which dormant projects need ongoing dependency alerts and whether organization policy handles that requirement centrally.