Cron expression explainer

Enter a five-field cron expression and choose its dialect. Read the selected schedule values and preview upcoming matching times after a UTC date.

Explain a schedule and calculate matching minutes locally. JavaScript is required.

How it works

The five fields select minute, hour, day of month, month, and weekday. Lists combine values; ranges include their endpoints; steps advance within a field and reset at its boundary. Month and weekday names use three letters. Unix accepts Sunday as 0 or 7, including ranges ending on Sunday such as FRI-SUN or 5-0; GitHub and Kubernetes accept 0.

Minute, hour and month must match. Restricted day-of-month and weekday fields use OR. Unix treats a leading asterisk in either day field as wildcard syntax and requires both day filters to match. Kubernetes uses its parser's wildcard flag: an unstepped wildcard anywhere in either day field selects AND; stepped wildcards with a step greater than one are restricted.

We inspect UTC minute boundaries strictly after the input instant and compare local calendar fields using the browser's time-zone database. No numerical rounding is applied to results. Missing wall-clock minutes are skipped; repeated minutes appear twice with different UTC timestamps. This is a schedule-matching preview, not a simulation of retries, concurrency, outages, or daemon-specific DST corrections.

Local resource limits: 1,024 expression characters, 50 results, and 70,272 UTC hour blocks per search (about eight years). If fewer matches are found, the result says so. Searches run in a worker to keep the page responsive.

Worked examples

Quarter-hour steps

For */15 * * * * in UTC, strictly after 2026-11-14T10:07:00Z, the next 3 runs are 10:15, 10:30 and 10:45 UTC on November 14.

Day-of-month OR weekday

For 0 9 1 * MON in UTC, after 2026-11-01T00:00:00Z, the next 3 runs are November 1, 2 and 9 at 09:00 UTC. November 1 matches the date; November 2 and 9 match Monday.

Leap day

For 0 0 29 FEB * in UTC, after 2025-01-01T00:00:00Z, the next run is 2028-02-29T00:00:00Z.

Frequently asked questions

Does this support Quartz?
No. Only five-field Unix, GitHub Actions, and Kubernetes are in scope. Quartz seconds fields and L, W, and # operators are rejected. Kubernetes accepts ? as a wildcard.
Which @macros can I use?
Unix and Kubernetes accept @yearly, @annually, @monthly, @weekly, @daily, @midnight and @hourly. Unix @reboot is explained but cannot produce calendar dates. GitHub requires five fields.
Are GitHub Actions always UTC?
UTC is the default. Current GitHub documentation also supports an optional timezone property. This tool deliberately previews only UTC GitHub schedules; it does not model that property or its DST behavior. The documented minimum interval is 5 minutes; matching times less than 5 minutes apart in the searched hours produce a warning, including across an eligible next hour or date.
How do I set a Kubernetes time zone?
Set .spec.timeZone to an IANA identifier such as Etc/UTC. Enter the same identifier here. Inline TZ or CRON_TZ assignments are rejected. Without .spec.timeZone, the controller uses its local time zone.
Does */23 mean every 23 hours?
In the hour field it selects hours 0 and 23 each day. Steps reset within their field; they are not elapsed-time timers. In Unix mode, write a range such as 20-59/15 rather than a starting-value step.
Are these guaranteed execution times?
No. These are matching calendar minutes. GitHub can delay or drop scheduled work, and Kubernetes concurrency or missed-run policies can change execution. Check your actual scheduler.

Sources

Last reviewed 2026-11-14; next review due by 2027-02-12. The method is written out above so you can check our math.