GitHub to Disable Dependabot Alerts on Inactive Repositories Starting December 8, 2026

What GitHub is changing​

GitHub's changelog entry says that from December 8, 2026 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 at any time. GitHub's stated reason is that vulnerability discovery and alert volume are growing quickly. The company says turning alerts off on idle repositories keeps Dependabot fast and reliable for actively developed ones.

The roadmap entry backs this up with similar wording. It says archiving alerts for inactive repositories frees up resources so security scanning stays fast and reliable for actively maintained repositories. GitHub has not published numbers on how many repositories are affected or how much performance improves. Treat the rationale as GitHub's own explanation.

What counts as activity​

GitHub lists three things that count:

• Pushing to any branch or tag.
• Creating the repository.
• Turning on Dependabot alerts.

The changelog does not list other actions. It doesn't say that opening a pull request, changing other settings, or viewing a repository counts as activity. It also doesn't say whether automated pushes qualify. Don't assume any of these count.

Turning alerts back on​

Any push to the repository automatically turns Dependabot alerts back on. You can also enable them in the repository's settings. Either way, GitHub restores the archived alerts and the one-year clock starts over.

GitHub Docs give the current navigation for the manual route:

1. Open the repository's main page on GitHub.
2. Click Settings. If the tab is hidden, open the dropdown menu first.
3. In the "Security and quality" section of the sidebar, click Advanced Security.
4. Next to Dependabot alerts, click Enable.

The docs list repository administrators, organization owners, and people with write or maintain access among those who can use this feature. Menu labels can change, so check the current interface if your view differs.

Exceptions: who keeps alerts regardless​

GitHub says it won't turn alerts off in two cases:

• Enforced security configurations. The repository must have an enforced security configuration that enables Dependabot alerts. A configuration that doesn't enable them, or one that isn't enforced, isn't covered by this exception.
• Enterprise policy. Repositories are skipped in enterprises whose Dependabot alerts policy doesn't let repository administrators enable or disable alerts. That doesn't make every enterprise repository exempt.

Administrators who rely on alerts for quiet repositories can use the enforced-configuration route to keep them on regardless of activity.

Scope: plans and deployment types​

The change applies to all plans on github.com and to GitHub Enterprise Cloud with data residency. For data residency customers, archived alerts stay in the same region as the rest of the enterprise's data. It does not apply to GitHub Enterprise Server.

What this does not change​

This is about alerts, not Dependabot's pull requests. GitHub already has a separate mechanism that pauses update pull requests. It pauses automated pull request activity when nobody has merged, closed, or otherwise interacted with Dependabot for over 90 days. That earlier change explicitly did not apply to Dependabot alerts or their notifications. The new change is a different, alert-level mechanism with a one-year inactivity trigger. Don't confuse the two.

Practical impact and open questions​

The risk is a false sense of safety. A repository can be quiet because it's finished, yet still be deployed, forked, or used as a dependency elsewhere. With alerts off, a newly disclosed vulnerability in its dependencies won't produce an alert. GitHub's announcement doesn't say whether findings published during the paused period are generated retroactively once alerts return. Until GitHub clarifies, don't assume they are.

Other unanswered points include how archived alerts appear in the UI and API, how long restoration takes, and whether GitHub will notify owners or provide a report of affected repositories. The changelog mentions none of these.

A sensible checklist before December 8:

1. List repositories with no pushes in the past year, including ones that still run in production.
2. Decide which still need alert coverage, and which should be archived or retired.
3. For those that need coverage, apply an enforced security configuration that enables Dependabot alerts, where your organization's setup allows it.
4. Remember that a push or manual enable restores alerts but restarts the one-year clock, so this is not a permanent fix without an exception.

Bottom line​

This looks like sensible capacity management on GitHub's side, and archiving rather than deleting keeps the security history intact. The trade-off is that dormant but still-used code will go quiet on vulnerability alerts unless someone opts it in through an enforced configuration or enterprise policy. If you maintain such code, check it before the December 8 start date.