Cron Expression Parser
β‘ Runs locallyπ No uploadsπ Free, no sign-up
A cron expression is the scheduling language of Unix-like systems: five fields β minute, hour, day-of-month, month, day-of-week β each describing a set of allowed values. An asterisk means every value, 1-5 is a range, 1,15 is a list, */15 is a step, and they compose (9-18/2 means every 2 hours from 9 AM to 6 PM). Every minute the cron daemon wakes up, matches the current time against each job's five fields, and runs the job when all of them match. The detail that trips up almost everyone: day-of-month and day-of-week are OR-ed. When both fields are restricted, the job runs when either one matches β not when both do. Most cloud schedulers β GitHub Actions, Vercel Cron, AWS EventBridge β accept the same five-field format, so one parser covers nearly every scheduled job you will meet.
Three everyday uses. First, inheriting a legacy crontab: you see "0 3 * * 1" and have no idea what it does β paste it in and get "runs at 3:00 AM every Monday" plus the next five concrete run times. Second, validating an expression you just wrote: is "*/15 9-18 * * 1-5" really "every 15 minutes on weekdays between 9 and 18"? The tool breaks down each field so you can confirm at a glance. Third, debugging a job that never ran: paste the production expression, check whether the upcoming run times match your expectation, and quickly tell a typo apart from a dead scheduler.
Know the boundaries. Five fields or six? Classic crontab uses five; six-field variants with a leading seconds field come from Node and Java schedulers like node-schedule or Quartz β this tool auto-detects the field count. Months and weekdays accept English abbreviations (jan, mon), case-insensitive, and both 0 and 7 mean Sunday. Invalid input gets a precise error naming the offending field: wrong field count, out-of-range values (minute 60), or a zero step. Impossible dates such as February 30th are skipped by cron itself, and this tool's "next 5 runs" walks a real calendar minute by minute, so it skips them too instead of inventing times.
Two warnings before you ship. First, upcoming run times are computed in your browser's local timezone, while server crons run in the server's timezone β convert before deploying when they differ, and watch out for daylight-saving transitions that can add or drop a run. Second, a single misplaced asterisk can turn "once a day" into "every minute". Always glance at the next five run times with this tool and confirm the rhythm before publishing.
How to use
- Paste or type a cron expression (5 or 6 fields), or click "Load example"
- Click Parse to get the plain-language meaning and a per-field breakdown table
- Check the next 5 run times to confirm the rhythm (browser local timezone)
- Copy the result to share with teammates or document the schedule
FAQ
What are the five cron fields?
In order: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), day-of-week (0-7, where 0 and 7 both mean Sunday). Some systems support a sixth leading field for seconds (0-59). All fields must match for the job to run β except day-of-month and day-of-week, which are OR-ed.
Day-of-month and day-of-week are both restricted β AND or OR?
OR. That is standard cron semantics and the most common beginner trap. "0 0 1 * 1" runs at midnight on the 1st of each month OR every Monday β not only when the 1st happens to be a Monday. If you need AND behavior, add the extra check inside your job script.
What do */15, 1-5 and 1,15 mean?
*/15 is a step: every 15 units (every 15 minutes in the minute field). 1-5 is an inclusive range. 1,15 is a list of discrete values. They compose, e.g. 9-18/2 means every 2 hours from 9 to 18. Note that steps start from the range minimum: 5-45/10 yields 5, 15, 25, 35, 45.
The next 5 run times are not what I expected. Why?
Check in this order: field count (five or six fields β is the first one seconds?), the day-of-month/day-of-week OR semantics, and month lengths (there is no February 30th; it gets skipped). Finally, confirm the timezone β this tool computes in your browser's local timezone, while server crons run in the server's timezone.
Are L, W, # and ? supported?
No. This tool covers standard crontab syntax (*, ,, -, / plus month/weekday abbreviations). Quartz extensions like L (last day of month), W (nearest weekday), # (nth weekday of month) and ? (placeholder) are a different dialect and need a Quartz-specific parser β pasting them here reports illegal characters.