Build the cron expression for your workflow's schedule trigger. GitHub Actions uses standard 5-field cron, always in UTC — generate and validate it below, then paste into your workflow YAML.
GitHub Actions Cron Generator: GitHub Actions schedules use standard 5-field cron syntax (minute hour day-of-month month day-of-week), evaluated in UTC with no timezone option and a 5-minute minimum interval. Build your expression above, then paste it into on.schedule.cron in your workflow YAML. Example: '0 6 * * 1-5' runs weekdays at 06:00 UTC.
Loading Tool...
Key Takeaways
Standard 5-field cron: minute hour day-of-month month day-of-week — no seconds field
ALWAYS UTC — there is no timezone setting; convert your local time before writing the expression
Minimum interval is 5 minutes (*/5) — anything tighter is rejected
Runs can be delayed or dropped at high-load times (top of the hour especially) — don't schedule at :00 if timing matters
Scheduled workflows are disabled automatically after 60 days of repository inactivity
What is GitHub Actions Cron Generator?
GitHub Actions Cron Generator — A GitHub Actions cron generator builds the 5-field POSIX cron expression used by the on.schedule workflow trigger — which GitHub evaluates in UTC only, with a 5-minute minimum interval.
The on.schedule trigger is how GitHub Actions workflows run on a timer — nightly builds, dependency scans, cleanup jobs, cron-driven deploys. It takes standard POSIX cron, but with platform rules that surprise people: everything is UTC (a '9 AM' schedule fires at 9 AM UTC, not your time), the shortest allowed interval is 5 minutes, GitHub may delay or skip runs during high-load windows, and repos with no activity for 60 days get their schedules disabled. Build and validate the expression below, copy the YAML, and check the examples table for the common patterns already converted.
How to Use GitHub Actions Cron Generator
1
Build your schedule in the generator above — it validates syntax and shows the expression in plain English.
2
Convert your intended local time to UTC (GitHub offers no timezone setting).
3
Paste the expression into your workflow: on: → schedule: → - cron: '<expression>'.
4
Avoid minute :00 for time-sensitive jobs — top-of-hour is GitHub's peak-delay window.
Key Features
About GitHub Actions Cron Generator
Ready-to-Paste Workflow YAML
name: nightly-job
on:
schedule:
- cron: "17 2 * * *" # 02:17 UTC daily — off the :00 rush
workflow_dispatch: # keep a manual trigger for testing
jobs:
run:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: ./scripts/nightly.sh
Two habits worth copying: an off-peak minute (17 above) so you dodge the top-of-hour delay window, and a workflow_dispatch trigger alongside the schedule so you can test the job without waiting for cron.
Common GitHub Actions Schedules
Goal
Expression
Notes
Every 15 minutes
*/15 * * * *
5-min floor applies; */15 is safe
Hourly, off-peak
23 * * * *
any minute except :00
Nightly 02:30 UTC
30 2 * * *
= 22:30 ET (summer) / 21:30 ET (winter)
Weekdays 09:00 New York
0 13 * * 1-5
EDT = UTC−4; use 14 during EST — DST needs manual updates
Every Monday 08:00 UTC
0 8 * * 1
day-of-week: 0/7 = Sunday
First of month, midnight UTC
0 0 1 * *
no L / W tokens — standard cron only
The UTC Trap (and the DST Corollary)
GitHub evaluates schedules in UTC with no override — the single most common Actions scheduling bug is writing local time into the cron field. Convert first, and remember daylight saving: a job pinned to "9 AM New York" is 13:00 UTC in summer but 14:00 UTC in winter, and your cron expression won't follow the clock change. Teams that care either accept the one-hour seasonal drift, update the workflow twice a year, or run the job hourly and gate it in a first step that checks the local time.
Delays, Drops, and the 60-Day Rule
Scheduled runs are queued, not guaranteed: during high-load periods (the top of every hour, and 00:00 UTC worst of all) runs commonly start minutes late, and GitHub documents that they can be dropped entirely under load. Schedule on odd minutes, and design jobs to tolerate a missed tick — idempotent, catch-up-friendly. Separately, public repos with no commits for 60 days get scheduled workflows suspended automatically (you'll get an email); any commit re-enables them. If a schedule "mysteriously stopped," check that first.
Frequently Asked Questions
What cron syntax does GitHub Actions use?
Standard 5-field POSIX cron: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), day-of-week (0-6, Sunday = 0 or 7). Ranges, lists, and steps (*/n) work; non-standard tokens like L, W, # and a seconds field do not. The generator above validates against exactly this grammar.
Can I set a timezone for a GitHub Actions schedule?
No — schedules always run in UTC and there is no timezone key. Convert your target local time to UTC when writing the expression, and remember to account for daylight saving (the UTC offset changes twice a year while your cron stays fixed).
Why didn't my scheduled workflow run on time (or at all)?
Three usual causes: high-load delay (runs at :00 routinely start late and can be dropped — use an odd minute), the 60-day inactivity suspension (no repo activity → schedules disabled until the next commit), or the workflow file isn't on the default branch — on.schedule only triggers from the default branch's copy.
What's the shortest interval GitHub Actions allows?
5 minutes (*/5 * * * *). Tighter expressions are rejected. If you genuinely need sub-5-minute cadence, run an external trigger (a scheduler pinging repository_dispatch) — or reconsider whether a queue/webhook fits better than polling.
Does this generator work for other CI cron formats too?
Yes for anything using standard 5-field cron (GitLab CI pipeline schedules, CircleCI, Jenkins' basic specs). Kubernetes CronJobs also use 5-field cron but add a timeZone field — see the dedicated Kubernetes CronJob schedule generator.