Cron Expression Generator & Explainer

About the Cron Expression Generator & Explainer

Paste a cron expression to see what it means — as a sentence and field by field — and exactly when it runs next, in any time zone. Or start from a common schedule or the visual builder and copy the expression. The six formats people actually use are covered, each with its own rules: Unix/Linux crontab (cronie, Debian’s cron), Spring’s six fields with seconds, Quartz, AWS EventBridge cron(), Kubernetes CronJob and GitHub Actions.

Errors say which field is wrong and how to fix it. The run list follows each scheduler’s documented behaviour on the days the clocks change, the same schedule is written for the other formats when it can mean exactly the same, and a ready-to-paste snippet (crontab line, @Scheduled, Quartz trigger, AWS CLI, CronJob manifest, workflow YAML) uses your time zone. Everything is computed in your browser.

Common uses

• Checking a crontab line before you install it, and seeing when it will next run on the server.
• Writing schedules for Kubernetes CronJobs, GitHub Actions workflows, AWS EventBridge Scheduler or Spring @Scheduled methods.
• Moving a schedule between systems — Quartz to Unix cron, crontab to EventBridge — without changing its meaning.
• Finding out what a job does on the night the clocks change.

The six formats compared

• Unix/Linux cron (cronie, Debian’s cron): 5 fields — minute, hour, day of month, month, day of week (0–7, Sunday is 0 or 7, or SUN–SAT). * , - / and names; @yearly, @monthly, @weekly, @daily, @hourly, @reboot. Runs in the server’s time zone; cronie also reads a CRON_TZ= line.
• Spring (@Scheduled, CronExpression): 6 fields, seconds first; day of week 0–7; ?, L, W and #; both day fields must match.
• Quartz: seconds, minute, hour, day of month, month, day of week (1–7, Sunday is 1), optional year (1970–2099). One of the two day fields must be ?. L, L-3, LW, 15W, 6L, 6#3.
• AWS EventBridge: cron(minutes hours day-of-month month day-of-week year) with the year required (1970–2199), day of week 1–7 (Sunday is 1), one day field ?, and L, W and #. EventBridge Scheduler runs in the zone you choose; legacy scheduled rules use UTC.
• Kubernetes CronJob: 5 fields, day of week 0–6, ? means the same as *, and @yearly … @hourly. Set the zone with .spec.timeZone (stable since v1.27); TZ= or CRON_TZ= in .spec.schedule is rejected.
• GitHub Actions: 5 fields with * , - /, day of week 0–6 or SUN–SAT, no @ nicknames. UTC unless the schedule has a timezone: key; at most every 5 minutes, and GitHub notes that runs at the start of the hour, a high-load time, can be delayed.

Day of month or day of week?

When both day fields are restricted, standard cron runs on days that match either one: 0 0 1 * 1 runs on the 1st and on every Monday. When one of them is *, only the other one counts.

Vixie cron and cronie decide this by looking at the first character: a day field that starts with * counts as unrestricted, so 0 0 */2 * 0 runs only on Sundays that fall on an odd date (Debian’s man page lists this as a limitation). Kubernetes’ parser treats */2 as restricted instead, so the same line means odd dates or Sundays there. Spring always requires both fields to match, and Quartz and EventBridge avoid the question by making you put ? in one of them. The tool applies the right rule for the format you choose and says so in the notes.

Daylight saving time

Cron fields are wall-clock times, so on the day the clocks change some times do not exist and others happen twice. The schedulers document different behaviour:

• Unix cron in the server’s own time zone (cronie and Debian’s cron, cron(8)): a job at a fixed time that the clocks skip runs right after they go forward, and it does not run a second time when they go back. A job whose minute or hour field starts with * (such as */15 * * * * or @hourly) follows the clock instead: skipped times do not run and repeated times run again.
• cronie with CRON_TZ=: in that zone, times that do not exist never match and times that happen twice run twice (crontab(5)).
• EventBridge Scheduler: a time that does not exist is skipped; a repeated time runs once.
• Kubernetes (robfig/cron): jobs scheduled in the skipped hour are not run.
• GitHub Actions: a run in the skipped hour moves to the next valid time — 02:30 becomes 03:00.
• Quartz says a change can cause a skip or a repeat; Spring does not say.

The run list follows these rules and marks moved, repeated and skipped runs. UTC never changes, which is why many teams schedule in UTC.

Last day of the month in Unix cron

Unix cron has no L. A common workaround runs on days 28–31 and lets the command check that tomorrow is the 1st:

0 9 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && /path/to/script.sh

date -d tomorrow is GNU date (Linux); on macOS and BSD use date -v+1d +\%d. The % has to be written \%, because in a crontab an unescaped % ends the command and starts its standard input. Quartz, Spring and EventBridge can simply use L in the day-of-month field.

Limitations

• Run times come from the expression alone; the tool cannot know a server’s clock, downtime or queueing delays (GitHub warns that scheduled runs can be delayed or dropped under high load).
• Non-standard extensions are not evaluated: cronie’s random ~ ranges, @every intervals, EventBridge rate() expressions and Jenkins’ H hash syntax.
• Quartz and Spring do not document what happens at clock changes; such runs are listed once and marked.
• The search looks up to 400 years ahead (Quartz stops at 2099, EventBridge at 2199), so a schedule that never runs is reported as such.

Privacy

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.