GitHub Dependabot alerts (December 2026): What Startups Need to Know

What did the vendor release?

GitHub published this Dependabot change on 10 November 2026. Starting 8 December 2026, GitHub 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.

Our recommendation: Use 8 December 2026 as a review deadline. Identify which quiet repositories you still want covered by Dependabot alerts. Give each repository an explicit decision: accept the pause or keep alerts enabled through an applicable exception.

Which startups are affected?

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

GitHub counts a push to any branch or tag, repository creation, or turning on Dependabot alerts as activity.

Our recommendation: Review repository activity separately from business importance. Ask whether each quiet repository still contains code your team uses or expects to maintain. Include repositories outside the current sprint plan. Assign an owner to decide whether alerts should remain enabled.

Adopt it or keep the existing approach?

GitHub will not turn off alerts on repositories with an enforced security configuration that enables Dependabot alerts. It also skips repositories in enterprises whose Dependabot alerts policy prevents repository administrators from enabling or disabling alerts.

Our recommendation: Keep alerts enabled for repositories that remain part of your product, even if development is quiet. For those repositories, review the enforced security configuration option and the enterprise policy exception. Verify that the chosen configuration or policy matches the exception as described.

Our recommendation: Accept the pause only where the repository owner agrees that alerts can be paused. Record that decision and who can revisit it. For a single repository that needs alerts restored, prefer the settings route over creating a push solely for this purpose.

What to check before enabling it?

Any push to a repository automatically turns Dependabot alerts back on. You can also turn them on in the repository's settings. Either method restores the archived alerts and restarts the one-year clock.

• Our recommendation: Check the hosting environment first. Confirm whether the repository is on github.com, GitHub Enterprise Cloud with data residency, or GitHub Enterprise Server. Use that result to decide whether this review applies.
• Our recommendation: Check activity against GitHub's listed events. Record the latest qualifying event for each repository under review. Use that record when deciding which repositories need attention before the change starts.
• Our recommendation: Check the exception precisely. Confirm that a security configuration is enforced and enables Dependabot alerts, or that the enterprise policy prevents repository administrators from changing the alert setting. Also verify whether alerts are currently enabled.
• Our recommendation: After restoring alerts, confirm that the setting is enabled and review the restored alerts. Record who owns the follow-up. Keep the decision and the applicable policy alongside your repository ownership notes.