What time zone does GitHub Actions use for schedule triggers?

UTC by default — a plain `cron:` entry is evaluated in UTC regardless of your repository or account time zone. GitHub also accepts an optional `timezone:` key next to `cron:` with an IANA name such as `America/New_York`; without it, build the expression here in UTC.

Why is there a 5-minute frequency warning?

GitHub's own documentation states scheduled workflows won't run more often than every 5 minutes, and may be delayed further during periods of high load on shared runners — this tool flags any schedule whose runs fall closer together than 5 minutes.

Can a workflow have more than one schedule?

Yes — add multiple `- cron: "..."` lines under `schedule:`. Generate each expression separately with this tool and combine them in your workflow file.

Does GitHub guarantee the schedule fires exactly on time?

No — GitHub Actions schedules are best-effort. During periods of heavy load, a run may be delayed or occasionally skipped, so avoid depending on second-level precision.

GitHub Actions Cron Generator

Build a GitHub Actions on: schedule: cron block from minute, hour, day, month and weekday fields, with a plain-English check and a 5-minute frequency warning.

Loading tool…

Worked examples

Every 30 minutes
The everyday case: a lightweight polling job, ready to paste under `on:` in a workflow file with no minimum-frequency warning.
Daily at 06:00 UTC
A nightly build or report job — a plain `cron:` entry is evaluated in UTC, so this fires at 6 AM UTC regardless of any contributor's local time (add a `timezone:` key to the schedule entry if you want local-time scheduling).
Every minute — flagged as too frequent
A syntactically valid cron expression that GitHub Actions won't honor as written — the warning catches this before it's committed to a workflow file.

What this tool does

This tool builds a cron expression from five fields and wraps it in a ready-to-paste on: schedule: YAML block for a GitHub Actions workflow file, along with a plain-English explanation and a warning if the schedule requests more frequency than GitHub Actions actually supports.

When you need it

Adding a scheduled trigger to a GitHub Actions workflow — a nightly build, a periodic health check, a recurring report — without hand-writing YAML indentation and cron syntax at the same time.
Reviewing a pull request that adds or changes a workflow's schedule, to confirm what it actually does before approving it.
Debugging a scheduled workflow that isn't firing when expected, by checking whether the schedule silently violates GitHub's minimum-frequency rule.
Converting a cron schedule from another system (a server crontab, a different CI tool) into the equivalent GitHub Actions configuration.

Schedules run in UTC unless you set a time zone

Unlike a server's crontab, which typically runs in that server's local time zone, a plain cron: entry in a GitHub Actions schedule: trigger is evaluated in UTC regardless of any time zone setting on your account or repository. A schedule built here to fire at "9 AM" means 9 AM UTC, not 9 AM in your local time zone. GitHub's workflow syntax also accepts an optional timezone: key on the same schedule entry, taking an IANA name such as Europe/London; with it, the expression is evaluated in that zone, including its daylight-saving changes. If you leave it out, convert your intended local time to UTC before building the fields.

The 5-minute frequency rule

GitHub's own documentation for scheduled workflows states that the shortest supported interval is once every 5 minutes, and that schedules can be further delayed or occasionally skipped during periods of high load on GitHub's shared runners. This tool checks whether the runs your expression produces ever fall closer together than 5 minutes — for example * (every minute), */2, or 1-10 — and shows a warning if so. The generated expression is still syntactically valid cron either way; the warning is about what GitHub will actually honor, not a syntax error.

Reading the YAML block

The output is formatted as a complete on: block with a schedule: array containing one cron: entry, matching the structure GitHub Actions expects at the top level of a workflow file. If your workflow already has other triggers (push, pull_request, workflow_dispatch), merge the schedule: entry into your existing on: block rather than having two separate on: keys, since YAML only allows one.

Multiple schedules

A single workflow can have more than one scheduled trigger — for instance, a lighter check every hour and a fuller run once a day. Generate each cron expression separately with this tool and add each as its own - cron: "..." line under the same schedule: array.

Best-effort, not guaranteed

Even a schedule that respects the 5-minute minimum isn't guaranteed to fire at the exact second requested — GitHub explicitly documents scheduled workflows as best-effort, with runs sometimes delayed during high load. Don't build logic that depends on second-level timing precision.

Frequently asked questions

What time zone does GitHub Actions use for schedule triggers?: UTC by default — a plain `cron:` entry is evaluated in UTC regardless of your repository or account time zone. GitHub also accepts an optional `timezone:` key next to `cron:` with an IANA name such as `America/New_York`; without it, build the expression here in UTC.
Why is there a 5-minute frequency warning?: GitHub's own documentation states scheduled workflows won't run more often than every 5 minutes, and may be delayed further during periods of high load on shared runners — this tool flags any schedule whose runs fall closer together than 5 minutes.
Can a workflow have more than one schedule?: Yes — add multiple `- cron: "..."` lines under `schedule:`. Generate each expression separately with this tool and combine them in your workflow file.
Does GitHub guarantee the schedule fires exactly on time?: No — GitHub Actions schedules are best-effort. During periods of heavy load, a run may be delayed or occasionally skipped, so avoid depending on second-level precision.