GitHub Actions schedule cron: why runs are late, and which minute to pick
A workflow with on: schedule: runs from a five-field cron expression, evaluated in UTC, on the default branch.
on:
schedule:
- cron: '17 3 * * 1-5' # 03:17 UTC, Monday to Friday
What is the shortest interval for a GitHub Actions schedule?
5 minutes. A cron such as * * * * * or */2 * * * * asks for more than GitHub supports, so it cannot run as often as written. If you need faster, trigger the work another way, for example with workflow_dispatch or a webhook.
Why does my scheduled workflow run late, or not at all?
GitHub documents that scheduled workflows can be delayed during periods of high load, that some queued runs may be dropped if the load is high enough, and that the start of every hour is a high-load time. A cron at minute 0, such as 0 * * * * or 0 3 * * *, lands on that peak. Choosing an odd minute such as 17 or 43 moves your run off it.
Why is my cron rejected or ignored?
GitHub cron has exactly five fields: minute, hour, day of month, month, day of week. A sixth "seconds" field from Quartz or Spring syntax is invalid.
Each number must sit in its range: minute 0 to 59, hour 0 to 23, day of month 1 to 31, month 1 to 12, day of week 0 to 6.
Times are UTC, so a local-time schedule needs converting, and daylight saving shifts do not move it.
Scheduled workflows run from the default branch, and GitHub documents that a public repository's schedules are disabled after 60 days without repository activity.
That exits with a nonzero status if any cron is flagged, so a bad one can be blocked in your own CI before it merges. GitHub's own documentation for the schedule event is the authority on current limits.