Cron Explainer
Cron strings are write-only: easy to paste, hard to read. This tool explains each field in plain words, flags common mistakes, and computes the next five run times from the current clock.
100% private — everything runs in your browser, nothing is ever uploaded.
What this tool does
A scheduled job runs at the wrong hour, and the crontab line */15 9-17 * * 1-5 does not say in plain words what it does. Cron expressions are effectively write-only: easy to copy, hard to read back, and several of their rules are genuinely surprising. This tool explains each of the five fields in ordinary language, flags common mistakes, and computes the next five run times from the current clock so you can confirm a schedule before deploying it. The union quirk in the day fields, step anchoring, and time zone assumptions are all frequent sources of real incidents. Reading the next five runs is the simplest sanity check there is: if the list shows a Saturday when you meant weekdays, the expression is wrong regardless of what you intended it to say.
How to use it in three steps
- Paste a standard five-field cron expression, for example */15 9-17 * * 1-5.
- Read the plain-language explanation of each field and any warning the tool raises about day-field or step behaviour.
- Check the next five run times. If they do not match the schedule you had in mind, adjust one field and compare again before putting it into production. Compare the next five runs against a calendar for the coming week before saving the expression to a crontab.
Questions people ask
Why does my job run on a day I excluded?
When both the day-of-month and day-of-week fields are restricted, standard cron treats them as a union rather than an intersection, so the job can fire on either matching day. Leave one of the two as an asterisk to get the behaviour most people expect.
Does the tool account for my server's time zone?
The next run times are calculated from the clock this page uses. If your server runs in UTC while you are working in a local zone, convert the intended hours to that zone before trusting the preview.
Are six-field or seconds-based expressions supported?
No. This tool explains the classic five-field form used by standard cron. Expressions with a seconds field, or platform-specific extensions such as @daily, need to be checked against that scheduler's own documentation.
What does a step such as */15 actually start from?
A step over a whole field is anchored at the field's minimum value, so */15 in the minute field fires at 0, 15, 30 and 45. Writing 5-50/15 instead starts at 5 and steps from there, which catches people out when they expect an offset schedule.
Privacy: Cron expressions and the next five run times are computed from your own clock inside this browser tab, so deployment schedules and internal job timings are never transmitted or stored.
How to use it
- Paste a 5-field cron expression, e.g.
*/15 9-17 * * 1-5. - Read the plain-language explanation of every field.
- Check the next five run times to confirm it fires when you expect.
Why it stays private
A mistyped cron expression in an ops runbook can fire a job at the wrong hour. Checking happens in your browser with no server involved — paste expressions containing internal hostnames freely.
Questions
Which cron dialect is supported?
The classic Unix 5-field format: minute, hour, day-of-month, month, day-of-week. Non-standard shortcuts like @daily and a 6th seconds field are not supported.
What is the difference between 0 and 7 in day-of-week?
Both mean Sunday. Some systems only accept 0, some only 7 — this tool accepts both and treats them identically.
Why do day-of-month and day-of-week both being restricted matter?
In classic cron, when BOTH fields are restricted (not *), a day matches if EITHER field matches — a famous surprise. The explanation calls it out so you can decide if that is what you meant.