Cron Expression Calculator
Paste a standard 5-field cron expression to get a plain-English explanation and the next few times it will actually run — or start from a common preset below.
Source: standard POSIX/Vixie cron syntax (crontab(5)). See the full methodology page. Reviewed: July 2026.
Field order and syntax
minute hour day-of-month month day-of-week
Each field accepts: * (any value), a single number, a range (1-5), a step (*/15 or 1-30/5), or a comma-separated list (1,15,30). Day-of-week accepts 0-7, where both 0 and 7 mean Sunday.
The one rule that trips people up: day-of-month AND day-of-week
If both the day-of-month and day-of-week fields are restricted (neither is *), standard cron runs the job when either condition is true — not when both are true. For example, 0 0 1 * 5 runs at midnight on the 1st of the month and every Friday, not only on Fridays that happen to be the 1st. If you only want one condition, leave the other field as *.
@-shorthand strings
Most cron implementations (including systemd and standard Vixie cron) also accept shorthand: @yearly/@annually (0 0 1 1 *), @monthly (0 0 1 * *), @weekly (0 0 * * 0), @daily/@midnight (0 0 * * *), @hourly (0 * * * *), and @reboot (runs once at startup — no fixed schedule, can't be shown as "next run times").
Does this work for Kubernetes CronJob schedules?
Yes — Kubernetes CronJob uses the same standard 5-field cron syntax. Just be aware CronJob schedules run in the cluster's configured time zone (or UTC by default in older versions), which may differ from your browser's local time shown here.
What about 6-field or 7-field cron (Quartz, some Windows schedulers)?
Quartz scheduler (common in Java apps) uses 6-7 fields including seconds and an optional year, which is a different syntax from standard Unix cron. This calculator only parses the standard 5-field format — entering a 6+ field expression will produce incorrect results.
Why do the "next run" times look different from my server?
This tool computes next-run times using your browser's local time zone. Your actual crontab runs in the server's configured time zone (often UTC on cloud instances) — if they differ, adjust for the offset when comparing.