GitHub Actions Cron
GitHub Actions uses standard 5-field Unix cron syntax in `on.schedule.cron`. The two things that catch people: the minimum interval is 5 minutes (not 1 like other platforms), and scheduled workflows can be delayed by tens of minutes during periods of high load. Schedules default to UTC, but since March 2026 you can add an optional `timezone:` field (IANA name) alongside each cron entry.
Quick reference
- Fields
- minute hour day-of-month month day-of-week
- Minute range
- 0–59
- Hour range
- 0–23
- Day-of-month range
- 1–31
- Month range
- 1–12 or JAN–DEC
- Day-of-week range
- 0–6 (Sun=0) or SUN–SAT
- Seconds
- Not supported
- Year
- Not supported
- Special chars
- * , - / (no @hourly etc shortcuts, no ? L W #)
- Timezone
- UTC by default; optional `timezone:` field (IANA name) per cron entry, since March 2026
- Minimum interval
- 5 minutes (not 1 minute!)
- Reliability
- Scheduled runs may be delayed during high GitHub load
Examples
| Expression | Description |
|---|---|
*/5 * * * * | Every 5 minutes (the fastest allowed) |
0 * * * * | Every hour, on the hour |
0 0 * * * | Daily at midnight UTC |
0 9 * * 1-5 | Weekdays at 9 AM UTC |
0 0 1 * * | First day of every month at midnight UTC |
0 0 * * 0 | Weekly on Sunday at midnight UTC |
Gotchas
- **Minimum interval is 5 minutes**, not 1. `* * * * *` (every minute) is invalid on GitHub Actions and silently fails to trigger. The fastest valid expression is `*/5 * * * *`.
- **Defaults to UTC, but timezones are now supported.** Since March 2026 you can add a `timezone:` field (an IANA name like `America/Los_Angeles`) next to each `cron:` entry, and GitHub handles DST for you. Older guides that say "GitHub Actions is UTC-only, offset the hour manually" predate this — you no longer need the two-entry PST/PDT workaround.
- **No shortcuts.** `@hourly`, `@daily`, etc. are NOT supported. Write the full expression every time.
- **Delayed under high load.** GitHub's docs explicitly note that scheduled workflows may be delayed — sometimes by 30+ minutes — when the platform is busy. If you need precise timing, use a different scheduler.
- **Workflows in inactive repositories get disabled.** GitHub disables scheduled workflows in repositories with no activity for 60 days. To keep them running, push at least once every 60 days or use the API to re-enable.
- **Multiple schedules allowed.** You can list several `cron` entries under `on.schedule` to fire on multiple schedules. Use `github.event.schedule` to detect which one triggered the run.
Used by
- GitHub Actions workflows (`on.schedule.cron`)
- GitHub Actions reusable workflows triggered on schedule
- Scheduled GitHub Pages deployments via Actions
GitHub Actions cron is just standard Unix cron with two important constraints — 5-minute minimum interval and “may be delayed under load.” For most workflows (nightly builds, weekly health checks, daily report generation) this is perfectly fine. For anything time-sensitive, use a more reliable scheduler.
References
Frequently asked questions
Why can't I run a GitHub Actions workflow every minute?
GitHub Actions enforces a minimum schedule interval of 5 minutes. `* * * * *` is technically valid syntax but will not trigger — the actual minimum is `*/5 * * * *`. If you need higher frequency, use a self-hosted runner with a local cron daemon, or a different platform entirely (Cloudflare Workers cron, AWS Lambda + EventBridge).
How do I schedule a workflow in my local timezone on GitHub Actions?
Since March 2026 you can add a `timezone:` field next to the cron entry with an IANA timezone name, and GitHub adjusts for daylight saving automatically:
```yaml
on:
schedule:
- cron: '0 9 * * MON-FRI'
timezone: 'America/Los_Angeles'
```
That runs at 9 AM Pacific year-round. Before this feature, GitHub Actions was UTC-only and you had to offset the hour manually (often with two cron entries for PST vs PDT) — that workaround is no longer necessary.
Why didn't my scheduled workflow run on time?
GitHub explicitly warns that scheduled workflows can be delayed during periods of high GitHub Actions load. Delays of 5–30 minutes are common; longer delays happen during peak usage. There's no SLA on scheduled run timing. If your workflow MUST run at a specific time, use a different scheduler (AWS EventBridge, Vercel cron, Cloudflare Workers) and have it dispatch the GitHub Actions workflow via the API.
Why did my scheduled workflow stop running?
Most likely your repository has been inactive for 60+ days. GitHub disables scheduled workflows in inactive repositories to conserve resources. Push any commit (even a no-op) to re-activate, or use the GitHub API to enable the workflow. To prevent it happening again, add a no-op weekly commit or activity ping.
Can I use the @hourly or @daily shortcuts?
No. GitHub Actions does not support the macro shortcuts like `@hourly`, `@daily`, `@weekly`, `@monthly`, or `@yearly`. Write the full cron expression instead: `0 * * * *` for hourly, `0 0 * * *` for daily, etc.