A GitHub Actions cron schedule is a five-field POSIX cron expression under on: schedule, evaluated in UTC unless you add a timezone key with an IANA zone name. Runs can start late at busy times such as the start of every hour, never run more often than every 5 minutes, only run from the default branch, and in a public repository the schedule switches itself off after 60 days without activity.
The same four runs a day, on and off the hour. GitHub names the start of every hour as a high-load time and publishes no bound on how late a queued run starts.
The builder checks an expression against GitHub's documented syntax, reads it back in words, and lists the next eight runs in UTC, in the workflow's time zone if you set one, and in yours, all computed in your browser. Nothing you type leaves the page. A short summary of the syntax comes first; time zones, late runs and who a scheduled run belongs to are answered after the tool.
Five fields, four operators
GitHub documents POSIX cron syntax: minute, hour, day of the month, month and day of the week, with JAN to DEC, SUN to SAT, and day of the week 0 to 6 with 0 as Sunday. Four operators work in any field, * for any value, , for a list, - for a range and / for a step, and GitHub's example 20/15 * * * * runs at minutes 20, 35 and 50 of every hour, not every 15 minutes from 0. When both day fields are restricted, POSIX matches a day that satisfies either, so 0 0 1 * MON also runs every Monday. The builder prints each valid expression as YAML under its run list, ready to paste.
FAQ
Why is my GitHub Actions scheduled workflow not running on time?
GitHub's documentation says the schedule event can be delayed during periods of high load, that the start of every hour is one of them, and that under enough load some queued jobs are dropped. Its advice is to pick a different minute: 17 */6 * * * keeps the four runs a day of 0 */6 * * *, at 00:17, 06:17, 12:17 and 18:17 UTC, and moves them off the busiest minute. If the workflow never runs at all, check that the file is on the default branch, because schedules run only from that branch's latest commit, so one added on a feature branch does nothing until it merges. In a public repository, also check that it has not been disabled after 60 days without activity.
Can GitHub Actions cron use a time zone other than UTC?
Yes. Since GitHub's changelog of 19 March 2026 you can add timezone: beside cron: with an IANA name such as Europe/Berlin; without it, schedules run in UTC, and the docs, read 2026-11-12, list the key for github.com, GitHub Enterprise Cloud and GitHub Enterprise Server from 3.22. A time in the hour skipped when clocks spring forward runs at the next valid time, so a 2:30 AM schedule runs at 3:00 AM that day, while the fall-back case, when an hour such as 1:30 AM happens twice, is not documented, so keep a job that must run once a day outside 1:00 to 3:00 local time, or in UTC. The builder marks any listed run that lands in a skipped or repeated hour.
Does GitHub Actions support @daily or @hourly?
No. GitHub's documentation says it does not support the non-standard syntax @yearly, @monthly, @weekly, @daily, @hourly or @reboot, and a sixth field for seconds is not accepted either; the builder rejects both and says why. Write the five fields instead: 17 3 * * * is a daily run at 03:17 UTC. To run on two different schedules, list two cron entries under schedule, and read github.event.schedule in a step to tell which one fired.
What is the shortest interval for a scheduled workflow?
Once every 5 minutes, per GitHub's documentation. An expression such as * * * * * is valid cron, but do not expect it to run every minute, and remember that runs near the top of the hour are the most likely to be delayed; the builder flags any expression whose runs fall less than 5 minutes apart. Add workflow_dispatch so you can run the job by hand while you test it, and set a concurrency group and timeout-minutes so a slow run and the next scheduled one do not overlap and a hung run does not hold a runner until the platform limit.
Who gets notified when a scheduled workflow fails?
Notifications go to the user who last modified the cron line in the workflow file, according to GitHub's documentation. A scheduled run still has an actor, and whoever changes the default branch becomes the actor for the schedules on it. If a schedule was disabled, a commit by someone with write access that changes the cron value turns it back on and makes them the actor, which also moves the notifications to them.
