Effective Dec 8 2026, GitHub will turn off Dependabot alerts on repositories that show no activity for twelve months. Existing alerts are not lost; they are archived and can be restored at any time. For teams that rely on continuous vulnerability detection, the pause means a repository can silently stop receiving new alerts unless activity resumes.
Dependabot alerts pause – activation rules
GitHub defines activity as any of the following actions:
- Pushing code to any branch or tag
- Creating the repository
- Enabling Dependabot alerts
- Re‑enabling alerts after they have been turned off
A single push automatically re‑activates alerts and restores the archived findings, resetting the one‑year inactivity timer. Alerts can also be turned back on manually via the repository settings, which triggers the same restoration process.
Operational impact
When alerts are paused, the notification pipeline stops delivering new vulnerability findings for the affected repository. Because the alerts are only archived, teams can retrieve them later, but any automated remediation or dashboard that expects live data will see a gap. Engineers should consider adding a check for alert status in CI/CD or monitoring scripts, especially for long‑lived or infrequently updated services.
Security policy interactions
Repositories that have an enforced security configuration explicitly enabling Dependabot alerts are exempt from the automatic pause. Likewise, enterprise accounts with a policy that prevents administrators from toggling alerts are skipped. The change applies to all GitHub.com plans and to GitHub Enterprise Cloud customers with data residency; archived alerts remain in the same geographic region as the rest of the enterprise data. GitHub Enterprise Server is not affected.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Teams should audit repository activity patterns and decide whether the default one‑year window aligns with their risk posture. If a repository is expected to be dormant but still requires vulnerability coverage, consider enforcing the security configuration that keeps alerts on. Document the restoration steps for archived alerts and incorporate a periodic verification that critical repos have not been unintentionally paused. Finally, monitor any enterprise policy settings that could override the pause behavior to ensure they match organizational expectations.