Tool
Cron expression explainer and run-time preview
Paste a 5-field cron expression for a plain-language explanation, per-field breakdown and the next 10 run times — computed in your timezone and shown side by side in UTC and Beijing time.
Expression
Processing: parsing and scheduling run entirely in this browser tab — nothing is sent or stored.
Field by field
Next 10 run times
GitHub Actions scheduled workflows are always interpreted in UTC; server crontab uses the machine's local timezone. A time that falls inside a DST gap is skipped, matching what real cron does.
What the explainer covers
Standard five-field cron — minute, hour, day of month, month, day of week — with *, lists 1,15, ranges 9-17, steps */5 or 9-17/2, and month/weekday names (mon, jan). Quartz extensions like L, W, # and six/seven-field forms with seconds or years are reported as unsupported rather than guessed.
When both day-of-month and day-of-week are restricted, the schedule fires when either matches — the classic cron gotcha — and the tool says so explicitly. Run times are computed in the timezone you pick: the expression is read as wall-clock time in that zone, converted to real instants across DST transitions, and shown side by side in your zone, UTC and Beijing time so "when does this GitHub Action actually run for me" answers itself.
FAQ
Which cron dialect does this explain?
Standard five-field cron (minute hour day-of-month month day-of-week) with *, lists, ranges, steps and month/weekday names. Quartz extensions (L, W, #, ?) and six/seven-field formats with seconds or years are reported as unsupported.
0 0 * * 1 and 0 0 1 * * look the same — are they?
No. The first runs every Monday; the second runs on the 1st of every month. And 0 0 1 * 1 runs on the 1st of the month OR every Monday — when both day fields are restricted, cron fires when either matches.
What timezone does GitHub Actions use for cron?
Always UTC — the schedule you write is interpreted in UTC regardless of where you or the runner are. Pick UTC in the timezone selector and read the Beijing-time column to see your local run times.
Why does a run time disappear or shift around DST changes?
A wall-clock time that falls inside a spring-forward gap does not exist in that timezone, so it is skipped — the same thing real cron does. Times around the autumn fallback fire once, at the first occurrence.