A scheduled GitHub Actions scan usually stops for one of four reasons: the repository was inactive for 60 days and the schedule was disabled, the workflow file is not on the default branch, the repository is a fork, or the run is delayed or dropped under heavy load. Each has a specific fix.
The four common causes
| Symptom | Likely cause | Fix |
|---|---|---|
| No runs for weeks on a quiet public repo | Auto-disabled after 60 days without activity | Re-enable the workflow |
| Workflow exists but never fires | File is not on the default branch | Merge it to the default branch |
| Works in the original, not in a fork | Forks start with schedules disabled | Enable it in the fork |
| Runs are late or missing at midnight UTC | High load at the top of the hour | Move the minute offset |
GitHub's documentation states that in a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days, and that forked public repositories have scheduled workflows disabled by default (disable and enable workflows).
Steps to diagnose
- Open the Actions tab and select the workflow. If it shows as disabled, use the Enable workflow button, or run
gh workflow enablewith the workflow name. - Check the branch. The events reference says scheduled workflows run on the default branch and use the latest commit there (events reference). A schedule defined only on a feature branch will never run.
- Read the cron line. GitHub uses five field cron syntax, runs in UTC unless you set a time zone, and does not support shortcuts such as
@daily. The shortest interval is every 5 minutes. - Avoid the top of the hour. The same page says the schedule event can be delayed during periods of high load, and that the start of each hour is a busy time. Use
17 2 * * *rather than0 0 * * *. - Check who gets the failure email. Notifications for scheduled workflows go to the user who created the workflow, and to whoever last changed the cron syntax after that (notifications for workflow runs). If that person left the team, nobody hears about failures.
Make it harder to fail silently
Add a manual trigger so you can test the job on demand:
on:
schedule:
- cron: "17 2 * * *"
workflow_dispatch:
Then add a check outside GitHub that confirms the scan completed. A scan that quietly stops is worse than no scan, because people assume they are covered. See how to monitor a scheduled scan that fails silently.
Quick check
Does a private repository lose its schedule after 60 days?
The GitHub text we checked names public repositories for the 60 day rule. Still confirm in your own Actions tab, and do not rely on the assumption.
Can I run the scan on a release branch?
Not through the schedule event directly, since it uses the default branch. Check out the release branches inside the job instead.
Sources
- GitHub: events that trigger workflows
- GitHub: disable and enable workflows
- GitHub: notifications for workflow runs
Last reviewed: 19 October 2026.
