GitHub Will Pause Dependabot Alerts on Inactive Repos Starting Dec. 8

GitHub will begin pausing Dependabot security alerts on dormant repositories starting December 8, 2026. If a repository has had no pushes, no new branches or tags, and no change to its Dependabot alert setting for a full year, GitHub will turn its alerts off. The underlying data isn't deleted — alerts are archived and automatically restored the moment anyone pushes to the repository again, which also restarts the one-year clock. GitHub says the change is meant to keep Dependabot fast for repositories that are still being actively developed, as the volume of alerts and newly discovered vulnerabilities keeps climbing.

The policy, announced in a GitHub Changelog post on November 10, 2026, affects every plan on github.com and GitHub Enterprise Cloud, including customers using data residency. It does not apply to GitHub Enterprise Server. Below is what actually changes, who is exempt, and how to get alerts back on if your repository gets swept up in the pause.

What is changing, and when

According to GitHub's own Changelog entry, titled "Dependabot alerts will pause on inactive repositories," the company will start turning off Dependabot security alerts on December 8, 2026 for any repository that has gone a full year without activity. This is a default behavior change rather than an opt-in: GitHub says it will apply automatically across eligible repositories rather than requiring action from repository owners.

It's worth being precise about the verb here. GitHub's post uses "pause," and in practice that means the alerting pipeline stops running new checks against the repository's dependency graph — it is not a deletion of security history, and it is reversible at any time, automatically or manually.

What counts as "activity"

GitHub defines "activity" narrowly for the purposes of this change. A repository is considered active, and therefore exempt from the pause, if any of the following happened in the past year:

Notably, activity that doesn't touch the git history or the alert setting — opening issues, commenting on pull requests, starring, forking, or browsing the repository — does not count toward keeping alerts active. Only pushes, repository creation, or toggling Dependabot alerts on reset the clock. That's a meaningful distinction for maintainers who think of a repository as "alive" because people still interact with it, even if nobody has pushed code in years.

Archived, not deleted

The most important nuance in the announcement is what happens to alerts that already exist on a repository when the pause kicks in. GitHub is explicit that existing Dependabot alerts are archived, not deleted, and can be restored at any time. Nothing about the underlying vulnerability data, alert history, or dismissal reasons is lost. The alerts simply stop being active and visible in the way they normally are until the repository becomes active again or someone flips the setting back on.

For organizations with large inactive archives — old internal tools, proofs of concept, forks nobody maintains anymore — this framing matters. It means a sudden change in alerting policy won't quietly erase a security paper trail that might matter later for an audit or incident investigation.

How to turn Dependabot alerts back on

There are two ways archived alerts come back, both outlined in GitHub's documentation on configuring Dependabot alerts:

• Push to the repository. Any push to any branch or tag automatically turns Dependabot alerts back on and restores whatever was archived. This happens without anyone needing to visit a settings page.
• Re-enable manually. A repository admin can go to the repository's Settings, open "Advanced Security" under "Security and quality," and click Enable next to Dependabot alerts. GitHub's documentation describes this as the same toggle used to turn Dependabot alerts on or off in general, not a special "unpause" control.

Either path restarts the one-year inactivity clock from that moment, so a repository that gets reactivated won't be at immediate risk of being paused again the next day.

Who is exempt from the pause

GitHub carved out two exemptions where alerts will stay on regardless of how long a repository has been inactive:

• Repositories covered by an enforced security configuration that enables Dependabot alerts. Organizations that push security configurations as mandatory policy — a feature GitHub has been expanding for Advanced Security customers — keep alerts running on every repository that configuration applies to, active or not.
• Repositories inside enterprises whose Dependabot alerts policy prevents repository administrators from enabling or disabling alerts. If an enterprise has locked that toggle at the organization or enterprise level so individual admins can't turn it off, the inactivity pause doesn't override that lock.

In practice, this means the pause is aimed squarely at the long tail of individually managed, unmanaged repositories — personal projects, old side repos, abandoned forks — rather than at fleets of repositories an enterprise has deliberately decided must always be scanned.

Which plans and products this applies to

GitHub says the change rolls out to all plans on github.com, plus GitHub Enterprise Cloud, including customers using GitHub's data residency option. For those customers, GitHub confirms that archived alert data stays stored in the same region as the rest of the enterprise's data, so the pause doesn't change where security data physically lives.

GitHub Enterprise Server is explicitly excluded. Self-hosted GitHub instances will not see Dependabot alerts pause due to inactivity under this change — at least not as part of this announcement.

It's also worth remembering what Dependabot alerts cost before this change even applies. Dependabot alerts have long been free on public repositories and included for organizations with GitHub Advanced Security on private repositories; this policy doesn't change pricing or licensing, it only changes whether the scanning stays switched on for a repository that nobody is touching. A repository that already pays for Advanced Security but sits idle for a year will still see its alerts archived unless it falls under one of the two exemptions above or an enforced security configuration keeps it running regardless of activity.

Why GitHub says it's doing this

GitHub's stated rationale is operational: the volume of Dependabot alerts and the rate of newly discovered vulnerabilities have both been growing quickly, and the company wants Dependabot's alerting pipeline to stay fast and reliable for repositories that are actually being developed. Scanning and re-scanning dependency graphs on repositories nobody has touched in years consumes processing capacity that could otherwise go toward surfacing alerts faster on active projects.

This is consistent with GitHub's broader pattern of tuning Dependabot's behavior around activity signals rather than treating every repository identically — the company previously changed how Dependabot's automated pull requests behave on inactive repositories, pausing those too after extended periods without interaction. This latest move extends a similar inactivity-based logic to the alerts themselves, which is a more consequential change since alerts (not just automated fix PRs) are the primary way teams learn about vulnerable dependencies in the first place.

GitHub's own documentation on how Dependabot alerts work explains that new alerts get created whenever GitHub's Advisory Database receives a newly reviewed vulnerability or whenever a repository's dependency graph changes, such as through a commit that updates a manifest or lock file. Both of those triggers scale with the number of repositories GitHub has to track and the number of advisories flowing into its database — and both keep growing as more organizations adopt dependency scanning and as more vulnerabilities get disclosed and reviewed each year. Pausing the subset of repositories where nothing is changing is, in effect, a way of narrowing that workload to repositories where new alerts can actually lead to a fix being shipped.

What it means if you maintain older repositories

For most actively maintained software, this change should be invisible: any regular commit activity keeps Dependabot alerts running exactly as before. Where it matters is the long tail of repositories that are finished, lightly maintained, or kept around for reference — old library versions, internal tools nobody has opened since a migration, student projects, or company forks of upstream open-source projects that are rarely rebased.

Those repositories can still be exposed to the internet, still get cloned, and in some cases still get deployed from, even without active development. An inactive repository that goes a year without alerts will not automatically re-notify anyone if a new critical vulnerability is published against one of its dependencies during that gap — the archived alert state means the backlog gets reconciled once activity resumes or alerts are manually re-enabled, not that notifications continue silently in the background. Teams responsible for organizational security posture, rather than individual contributors, are the ones who most need to know this is coming, since they're the ones likely to run audits of dormant repositories before December 8.

This sits in the same broader territory as other recent GitHub platform changes affecting how repositories get monitored and secured by default — alongside things like GitHub's expansion of secret scanning detectors and the ongoing response to supply-chain incidents such as the campaign that hit tens of thousands of GitHub repositories earlier this year. Dependabot itself sits within GitHub's broader platform built on top of Git, and is one of the main automated tools GitHub offers for catching vulnerable dependencies before they ship.

Practical steps before December 8

Organizations that want to avoid surprises have a short window to check their repository inventory. A few concrete steps:

• Audit repositories that haven't had a push in the last year, particularly ones still running in production or still publicly cloneable.
• Decide whether to push a trivial commit, re-enable alerts manually, or set up an enforced security configuration for any repositories you want to keep monitored regardless of activity.
• For regulated or compliance-sensitive environments, consider whether an enterprise-level policy locking the Dependabot alerts toggle makes more sense than relying on individual repository admins to remember.
• If a repository is genuinely abandoned and not deployed anywhere, letting its alerts pause is likely the correct outcome — that's the behavior GitHub designed this change to produce.

What's next

The pause takes effect December 8, 2026, and GitHub has not announced a phased rollout or opt-out period beyond the exemptions already described. Expect GitHub to publish follow-up guidance closer to that date, likely through its documentation on Dependabot alerts and possibly through additional Changelog posts if the rollout surfaces edge cases — for instance, around how archived alerts interact with third-party integrations that poll the Dependabot alerts API, or how security teams can bulk-audit inactive repositories ahead of the deadline. Until then, the most reliable way to confirm a specific repository's status is to check its Security tab directly or review GitHub's own Dependabot alerts documentation linked throughout this article.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage