About the Cron Explainer
The cron explainer takes a standard five-field cron expression and tells you exactly when it will run. Paste in something like 0 9 * * mon and it validates each field, then lists the actual upcoming run times in your own local timezone instead of leaving you to work it out by hand.
It exists because crontab syntax is compact by design and easy to misread under pressure. A single misplaced comma or a step value in the wrong field silently turns a daily job into an hourly one, or skips a day entirely. Rather than trusting a mental model of what an expression "should" do, you see the concrete next five run times before the schedule ever touches a real server.
The parser supports the classic five fields (minute, hour, day of month, month, day of week), with asterisks, comma-separated lists, dash ranges, slash steps, and three-letter month and weekday names like jan or fri. It follows the standard POSIX rule for the two day fields: when both day of month and day of week are restricted at the same time, a match on either one is enough, which is the part of cron that trips up the most people.
Everything runs client-side in the browser. The expression you type and the run times it computes never leave your machine, so it is safe to test a schedule that references internal job names or paths without worrying about where that string ends up.
How to use it
- Enter a five-field cron expression, such as 30 4 * * 1-5.
- Check that the field turns green with no validation error.
- Read the next five computed run times, shown in your local browser timezone.
- Adjust a field and watch the run times update immediately.
- Use weekday or month names like mon or jan if numeric fields are hard to read at a glance.
- If the tool reports "never matches", check for a day-of-month value that does not exist in every month, such as 31.
Examples
- 0 9 * * mon runs once, at 09:00, every Monday.
- */15 * * * * runs every 15 minutes, all day, every day.
- 0 0 1 jan * runs at midnight on the 1st of January each year.
- 30 4 * * 1-5 runs at 04:30 on weekdays only (Monday through Friday).
- 0 */6 * * * runs every 6 hours, at minute 0 (00:00, 06:00, 12:00, 18:00).
- 0 22 * * 0,6 runs at 22:00 on Saturday and Sunday only.
The five fields, in order
Cron reads left to right as minute, hour, day of month, month, day of week. Getting the order backwards is the single most common crontab mistake, especially for anyone coming from a different scheduler where the order runs the other way.
- Field 1, minute: 0-59
- Field 2, hour: 0-23 (24-hour clock, no AM/PM)
- Field 3, day of month: 1-31
- Field 4, month: 1-12, or jan-dec
- Field 5, day of week: 0-7, where both 0 and 7 mean Sunday, or mon-sun
Operators and what they actually do
Each field accepts a small set of operators that combine, and reading them wrong is the second most common source of scheduling bugs.
- * matches every value in that field's range
- , separates a list, such as 1,15 for the 1st and 15th
- - defines an inclusive range, such as 9-17 for 9am through 5pm
- / defines a step, and */15 means every 15 units starting from the field's minimum, not just the value 15
- */15 and 15 are not interchangeable: */15 in the minute field fires at 0, 15, 30 and 45, while a bare 15 fires only once, at minute 15, every matching hour
The day-of-month and day-of-week trap
When both the day-of-month field and the day-of-week field are restricted (neither one is a bare asterisk), most cron implementations treat the match as an OR, not an AND. So 0 0 13 * fri does not mean "only Friday the 13th", it means midnight on the 13th of every month, OR every Friday, whichever comes first in a given week. This one rule accounts for a large share of "why did my job run on the wrong day" reports. To require both conditions at once, restrict only one of the two day fields and filter the other in the job script itself.
What this parser does not cover
It intentionally sticks to the classic five-field format used by cron and crontab.
- No seconds field: six-field "quartz-style" expressions used by some Java schedulers and CI systems are not parsed here
- No @-macros: shortcuts like @daily, @hourly or @reboot are not expanded, since they are shell/cron-daemon conventions rather than part of the five-field syntax itself
- No non-standard extensions: some cron variants add L (last day), W (nearest weekday) or # (nth weekday); these are not supported
- Next-run preview is capped at scanning one year ahead; an expression that legitimately never matches within a year (for example day-of-month 31 combined with February) reports as never matching
Frequently asked questions
What cron format does this tool use?
The standard five-field format: minute, hour, day of month, month and day of week. It supports asterisks, comma-separated lists, dash ranges, slash steps, and three-letter month or weekday names.
What timezone are the next run times shown in?
Your local browser timezone. The tool reads the time from your device, so the preview matches what you would actually see on your own machine or server clock, provided that clock is set to your local zone.
Does it support six-field cron with seconds?
No. This parses the classic five-field crontab format only. Six-field expressions with a leading seconds field, used by some CI tools and Quartz-style schedulers, are not supported.
Can I use @daily, @hourly or @reboot?
No. Those macros are shortcuts expanded by specific cron daemons, not part of the five-field expression syntax itself, so this parser does not expand them. Write out the equivalent five fields instead, for example 0 0 * * * for @daily.
What does */15 mean versus just 15?
*/15 is a step value meaning every 15 units within the field's full range, so in the minute field it matches 0, 15, 30 and 45. A bare 15 matches only the single value 15, so it fires once per matching hour instead of four times.
Why does my job run on days I did not expect?
This usually happens when both the day-of-month and day-of-week fields are restricted at once. Standard cron treats that combination as an OR: the job runs if either field matches, not only when both match simultaneously.
How do I schedule a job for weekdays only?
Use a range or list in the day-of-week field with day-of-month left as an asterisk, for example 30 4 * * 1-5 or 30 4 * * mon-fri, both meaning 04:30 every Monday through Friday.
Is my cron expression sent to a server?
No. Parsing, field validation and the next-run calculation all happen locally in your browser. Nothing about the expression, including any internal job names embedded in a comment, is uploaded anywhere.
Can weekday numbers be 0 or 7 for Sunday?
Yes. Both 0 and 7 represent Sunday in the day-of-week field; this tool treats them as equivalent, matching standard cron behavior.
Why does the tool say a schedule never matches?
This happens when the day-of-month value cannot occur in any month that also satisfies the month field, most often day 31 combined with a 30-day or shorter month, or February 29 outside a leap year within the one-year lookahead window.