GitHub states that in a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days. A stable, rarely changed package can therefore lose its weekly audit job without any error. Re-enable it, and add a second signal so you notice.
What the rule says
The GitHub documentation on disabling and enabling workflows says: in a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days. The sentence does not define what counts as activity here, so read the current page before relying on a specific action.
That matters for a solo maintainer. A small, finished library may not change for months. If your only audit runs on a cron schedule, it can quietly stop just when a new advisory lands against an old dependency.
How to tell if it happened
- Open the Actions tab and look at the workflow list. A disabled workflow shows a notice and an enable button.
- Look at the date of the last run. A weekly job with a last run older than two weeks is suspect.
- Check your email for GitHub notices about the workflow.
Ways to cope
| Approach | How it helps | Trade off |
|---|---|---|
| Re-enable by hand after each notice | Cheap | Easy to miss |
| Run the schedule from somewhere else, such as a small server cron that calls a script | Not tied to repo activity | You maintain another thing |
| Turn on the advisory alerts GitHub already offers for dependencies | Event driven, not time driven | Less control over format |
| Use a scan service that re-checks you continuously | Not repository bound | Needs an account |
| Add a calendar reminder to run the audit | Human backstop | Needs discipline |
A time driven job and an event driven alert cover different gaps. We compare them in dependabot alerts versus security updates versus version updates and in triggering a scan when a new advisory is published.
Make the job loud when it fails
If a scheduled audit finds something, it should create an issue or notification, not just a red mark in a tab nobody opens. Also make the job fail when the audit finds a high severity issue, as in gating a release on the audit exit code, and watch the repo as described in who watches security alerts when the solo maintainer is away.
A solo routine that does not depend on cron
- Pick a fixed day each month and run the audit by hand. Our 30 minute weekly routine for solo developers fits.
- Keep the scheduled job as a bonus, not the only check.
- After a long quiet stretch, push a small commit, or enable the workflow again, then confirm a run appears.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how monitoring keeps checking a project after the build is done, with no cron file to maintain.
Quick check
Does this apply to private repositories?
The sentence I confirmed refers to public repositories. Check the GitHub page for your case.
Is a disabled schedule reported as a failed run?
Not that I could confirm. Check the Actions tab for the notice and the last run date.
Sources
Last reviewed: 19 October 2026.
