Scheduled scans can stop without any error. GitHub runs scheduled workflows only from the default branch, can delay or drop them under heavy load, and disables them in public repositories after 60 days with no repository activity. Add a heartbeat check so silence is never mistaken for a clean result.
What GitHub documents
From the Actions documentation on the schedule event:
- Scheduled workflows run on the latest commit of the default branch, and the workflow file must exist there.
- Runs can be delayed during periods of high load, which peaks at the start of each hour. Under high load, some queued jobs may be dropped. Choosing a different minute of the hour reduces the risk.
- The shortest interval is once every five minutes.
- In public repositories, scheduled workflows are disabled automatically after 60 days with no repository activity. They can be re-enabled.
- Schedules use UTC unless you set a time zone with the timezone key.
- Standard five field cron syntax is used, and shorthand like daily is not supported.
Ways a scan stops without telling you
| Cause | Symptom |
|---|---|
| Workflow edited on a feature branch only | Schedule never fires from that branch |
| Quiet public repository | Schedule disabled after 60 days |
| Cron set to the top of the hour | Occasional delayed or missing run |
| Token or credential expired | Run fails and nobody reads the failure |
| Failure notifications go to a person who left | Failures pile up unseen |
Add a heartbeat
A heartbeat turns absence into an alert.
- Have each scan publish a last-success timestamp, in a file, a status check or a monitoring metric.
- Create a separate check that fails when the timestamp is older than your allowed gap, for example two cycles.
- Send that failure somewhere a team reads, not an individual inbox.
- Include the repository and workflow name in the message so the fix is quick.
Reduce the chance of drift
Pick an off-peak minute, such as 17 past the hour, rather than the top. Keep scheduled workflows on the default branch and review them like production code. For quiet public repositories, add a periodic maintenance commit or a reminder to re-enable the workflow. Assign the workflow an owner in a code ownership file.
Test it
Once a quarter, temporarily break a scan on purpose in a test repository and confirm the heartbeat fires. A monitor you have never seen alert is a monitor you do not know works.
For the choice between event and schedule triggers, see scan on commit, on schedule or both.
Where Safeguard fits
Safeguard's dependency scanning can run as part of your pipeline, and its policies and gates give a pull request level check that does not depend on a schedule. A free scan is a quick way to see a baseline.
Quick check
Why did my scheduled workflow not run last night?
Check that the file is on the default branch, that the repository has not been inactive for 60 days if it is public, and whether the run was delayed or dropped under load.
Does a green dashboard mean the scan ran?
Not unless the dashboard shows a recent run time. Add a last-success check.
Sources
Last reviewed: 19 October 2026.
