GitHub Actions cron picker

Why GitHub Actions cron is harder than it looks

On paper, GitHub Actions uses the same 5-field Unix cron you have used for years. In practice, three quirks turn a five-second config change into an outage. First, theon.schedule.cron trigger has no timezone: field. Every expression runs in UTC, full stop, which is the single biggest reason teams in London ship "every weekday at 9am" workflows that fire at 10am for half the year.

Second, GitHub silently raises any cadence under 5 minutes to */5. Write*/1 * * * * and you will not get an error, you will get a schedule that runs twelve times an hour instead of sixty. The picker above flags this for you.

Third, scheduled workflows pause themselves on inactive repos. After 60 days with no commits, no PRs, no manual interaction, GitHub disables the schedule until somebody does something. If you run a nightly mirror or a weekly digest off a repo that nobody touches, the job goes dark and you do not get an email. The cure is to land a noop commit (or trigger a manual run) every couple of months.

The two-cron pattern for non-UTC schedules

Because GitHub Actions has no timezone field, every "9am London" workflow needs to shift its UTC hour twice a year. The fix is two cron lines and a comment, not one cron and a hope.

London during GMT (winter) is UTC+0, so 9am London is 9am UTC. London during BST (summer) is UTC+1, so 9am London is 8am UTC. Split your schedule by month: one cron covers the winter months at 0 9, the other covers the summer months at0 8. The picker above generates the snippet for you with the right comments.

There is a small honesty tax. DST switches on the last Sunday of March and the last Sunday of October, not on month boundaries. For the two or three weekdays between the month boundary and the actual DST switch, your job will fire an hour off. If precise wall-clock timing matters, run the workflow through a self-hosted runner withTZ=Europe/London set, or use the time zone converter to double-check the days that straddle the cliff.

What heavy minutes do to your job lag

Every workflow on GitHub that schedules 0 * * * * wakes up at the same instant. So does every */5 * * * *, every 0 0 * * *, every round number. GitHub adds jitter to spread the load, but during peak hours the five-to-twenty minute lag is real and undocumented.

If your job needs to start promptly, do not pick the round minute. 3 * * * * runs once an hour at minute 3 and lands almost on time, because almost nobody else picked it. 0 * * * * shares its slot with everyone in the world who took the obvious answer.