Your code still runs. Will Dependabot still alert you?

A small service runs every night. It does its job, so nobody has pushed a code change for months. Is it still receiving the dependency warnings its team expects?

That question has become more urgent after GitHub’s 10 November announcement about pausing Dependabot alerts on inactive repositories. A repository stores a project’s code. Dependencies are the external packages that code uses. Dependabot can flag known vulnerabilities in those packages.

The practical task is to find projects that remain useful after active development stops, then check how their security coverage will continue. A quiet code history tells you little about who still depends on the software.

What changes on 8 December

GitHub says that from 8 December 2026, it will switch off Dependabot alerts on most repositories with no qualifying activity during the previous year. Existing alerts will be archived and can be restored.

Qualifying activity includes creating the repository, pushing to a branch or tag, or enabling Dependabot alerts. A push or manual re-enablement restores archived alerts and restarts the year. The change covers all plans on github.com and Enterprise Cloud with data residency, excluding Enterprise Server.

There are exceptions: enforced security configurations that enable alerts, and enterprise policies that prevent repository administrators from toggling alerts. Check the actual configuration before assuming an exemption.

This is an announced future change. It is not evidence that your alerts have already paused, or that a particular repository has been compromised.

Separate three questions

Dependabot’s documentation describes alerts generated from reviewed advisories and changes to the dependency graph on the default branch. An alert can identify an affected file, severity and an available fixed version. Keeping manifests and lock files accurate supports that analysis.

First ask whether alert generation is enabled. Next ask whether someone receives and reviews notifications. Finally ask how the team makes and verifies a repair. An automated pull request proposing an update is a further step, not the same thing as receiving an alert.

Notification preferences can differ from alert settings. GitHub also says initial enablement does not notify people about every existing vulnerable dependency. After restoring coverage, inspect the alert list directly rather than waiting for an email.

For a product owner or delivery lead, these distinctions help turn a vague request to keep Dependabot working into a specific conversation with the repository administrator.

A worked example: quiet does not mean retired

Consider this illustrative example: Priya is reviewing four repositories for a small organisation. She begins with where their software is used, then checks activity and settings. The rows below are constructed teaching records, not findings from a real organisation.

Her first pass produces a decision table. It records what to investigate next; it does not certify any repository as secure.

The exporter becomes Priya’s first continuity question because its nightly use would be easy to miss in a list sorted by recent commits. The library needs a different check: evidence that its exception is applied. The training sample needs an explicit retirement decision.

None of these decisions follows from age alone. A repository can be old and essential, active and poorly maintained, or genuinely ready to retire.

Make the coverage decision concrete

For an individual repository, GitHub’s instructions point to Settings, then Advanced Security under Security and quality, where an authorised administrator can enable Dependabot alerts. If you lack access, ask the owner to confirm the setting rather than guessing from an empty inbox.

For organisation-wide continuity, discuss an enforced configuration with the security owner. Enforcement prevents changes to the features it explicitly sets. Check which repositories it actually covers; making a configuration the default for new repositories does not establish coverage for every existing project.

Enterprise owners can also review the policy governing repository administrators’ Dependabot controls. Review the effect across the organisation before changing a central policy.

Manually re-enabling a feature can restore coverage, but it leaves another future review to remember. Choose a supported approach that fits the project’s lifespan. Avoid creating meaningless commits solely to make an inventory look busy.

A twenty-minute continuity review

Choose three repositories that have changed little but might still support a service, scheduled job or shared package. Ask a colleague who understands their operational use to review them with you. Record these six fields for each:

Keep unknowns visible. If nobody can confirm whether a service still runs, assign that investigation before deciding its security monitoring is unnecessary. Retirement should include the deployed software and its dependencies, rather than merely tidying the repository list.

Your next step is small: find one quiet repository that people still rely on and confirm its alert continuity before 8 December. The useful outcome is a documented maintenance decision backed by settings and operational evidence.