Cron expressions are short but not exactly easy to read at a glance. Instead of digging through documentation to figure out exactly when */15 9-17 * * 1-5 fires, paste it in here for a plain-English description and the actual next run times.
Field syntax
Standard cron reads left to right as minute, hour, day of month, month, and day of week — 5 fields. This tool also recognizes a 6-field form with a seconds field added at the very front (second, minute, hour, day of month, month, day of week).
- Minute: 0-59
- Hour: 0-23
- Day of month: 1-31
- Month: 1-12 or JAN-DEC
- Day of week: 0-7 (both 0 and 7 mean Sunday) or SUN-SAT
- Second (6-field form only): 0-59
Each field accepts:
*— every value (“every minute”, “every hour”)5— an exact value1-5— a range (Monday through Friday)*/15— a step (starting from 0, every 15: 0, 15, 30, 45)1,15,30— a comma-separated list
Common macros are supported too: @yearly (0 0 1 1 *), @monthly (0 0 1 * *), @weekly (0 0 * * 0), @daily (0 0 * * *), and @hourly (0 * * * *). @reboot has no fixed time, so it isn’t supported.
Flavor differences: Unix cron vs. Quartz vs. cloud schedulers
“Cron expression” doesn’t mean exactly the same syntax everywhere.
- Unix cron (crontab): The standard 5 fields. Day of week runs 0-7 (both 0 and 7 mean Sunday), and fields only support values, ranges, lists, and steps (
*/n). - Quartz (the Java scheduler): 6 or 7 fields, with seconds at the front and an optional year at the end. Day of week runs 1-7 (1 = Sunday) instead of Unix cron’s 0-7, and it adds tokens Unix cron doesn’t have:
L(last day of the month or week),W(nearest weekday),#(e.g.6#3= the third Friday), and?(leave day-of-month or day-of-week unspecified). Quartz also won’t let both day-of-month and day-of-week be*at the same time. - Cloud schedulers (AWS EventBridge, Google Cloud Scheduler, and similar): Broadly similar to Unix cron, but the details can differ. AWS EventBridge, for instance, follows the Quartz-style 6-field layout (minutes through an optional year, no seconds field) and requires a
?in either day-of-month or day-of-week.
This tool validates and describes only the standard 5- or 6-field (seconds-first) syntax. Quartz- or cloud-provider-specific tokens (L, W, #, ?, a year field, and so on) aren’t supported, so double-check against that service’s own documentation before you actually schedule something there.
Daylight saving time pitfalls
When you pick a time zone to compute next run times, it helps to know two things about DST transitions:
- A missing hour on the spring-forward day. The day clocks jump forward, a specific local time (often in the 2 AM hour) never happens at all. The date library behind this tool resolves that missing time using the offset from before the transition.
- A repeated hour on the fall-back day. The day clocks are set back, a local time occurs twice. This tool shows that time only once, not twice.
If you have a job scheduled to run between 1 and 3 AM, it’s worth checking its next run times around DST transition dates with this tool.