Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Starting December 8, 2026, GitHub will act on most repositories with no activity in the previous year; existing alerts will be archived, not deleted.
- The announcement lists pushes to any branch or tag, repository creation, and enabling Dependabot alerts as activity.
- A push automatically re-enables alerts; you can also enable them in repository settings. Either action restores archived alerts and restarts the one-year clock.
- Repositories covered by an enforced security configuration that enables alerts, and repositories under a specific enterprise policy, are exempt. GitHub Enterprise Server is excluded.
The change starts on December 8, not today
In a November 10, 2026 announcement, GitHub said it plans to turn off Dependabot alerts on most repositories with no activity in the past year, starting December 8. This is a future change; the announcement does not show that alerts on any particular repository have already been turned off. It also gives no per-repository execution time or time zone.
Existing alerts will be archived, not deleted, and can be restored later. Archiving preserves the records; it does not mean that the underlying vulnerabilities have been fixed.
What the announcement counts as activity
GitHub lists three qualifying activities: pushing to any branch or tag, creating the repository, and turning on Dependabot alerts. For an existing repository, a push to any branch or tag counts; enabling alerts also counts. The rule uses a one-year activity window, but the post does not specify the exact processing cutoff for each repository.
The post does not say that viewing a repository, starring it, opening an issue, commenting on a pull request, or browsing alerts resets the clock. Do not rely on those actions to keep alerts on, and do not infer the activity state of a repository you have not checked.
How to turn alerts back on and restore them
A push to any branch or tag automatically turns Dependabot alerts back on. You can also enable alerts in repository settings. GitHub says either route restores archived alerts and starts the one-year clock over.
GitHub’s documented path is repository Settings > Security and quality > Advanced Security > Dependabot alerts. Someone with the required permission can select Enable. The available controls still depend on actual access and organization or enterprise policy.
For a repository still under development, use a normal, useful push when one is due. If a push is not appropriate, enable alerts in settings instead. Verify the state in GitHub afterwards; the announcement gives no per-repository restoration time.
Exemptions and supported GitHub deployments
GitHub says it will not turn off alerts on repositories covered by an enforced security configuration that enables Dependabot alerts. It also exempts repositories in enterprises whose Dependabot alerts policy prevents repository administrators from turning alerts on or off. Eligibility depends on the actual configuration and organization or enterprise policy; a repository name alone cannot establish it.
The change covers every plan on github.com and GitHub Enterprise Cloud with data residency. For those data-residency customers, archived alerts stay in the same region as the rest of the enterprise data. GitHub Enterprise Server is excluded. The post does not announce pricing changes, changes to Dependabot security or version update pull-request schedules, or the current settings of any account or repository.
A practical check for repository teams
Make a list of repositories that are still in use but may have had no push in the past year. An authorized maintainer can check whether Dependabot alerts are enabled, whether an enforced security configuration enables them, and whether an organization or enterprise policy controls the setting. For repositories that still need alerts, plan an ordinary maintenance push or re-enable alerts in settings.
GitHub has not exposed your repository’s state or supplied a per-repository processing schedule. After checking, record the alert state and applicable policies you actually see so the team can review them during later maintenance.
Sources
Frequently Asked Questions
Does upgrading to a paid plan automatically exempt a repository?
The announcement does not list upgrading as an exemption, and the policy covers all plans on github.com. Check the actual enforced security configuration or enterprise Dependabot alerts policy; a paid subscription alone does not establish eligibility.
Is maintenance complete once archived alerts are restored?
Restoring alerts and fixing dependency vulnerabilities are separate tasks. Review each alert, update relevant dependencies through your normal maintenance process, test and release the changes, then check the actual alert state. Restoring alerts does not prove that a vulnerability is fixed or that a fresh scan has finished.