Worked Examples
Weekdays at nine
- Input
0 9 * * 1-5- Output
At 09:00 on Monday, Tuesday, Wednesday, Thursday and Friday.
The day-of-week range covers Monday to Friday. Only one day field is restricted, so ordinary AND semantics apply.
The OR rule catching someone out
- Input
0 0 1 * MON- Output
At 00:00 on day 1 of the month, and also on Monday.
This does not mean "the 1st, but only when it is a Monday". Because both day fields are restricted, cron fires on the 1st AND on every Monday — roughly five times a month rather than once or twice a year.
A step over a range
- Input
0 9-17/4 * * *- Output
At 09:00, 13:00 and 17:00.
The step applies within the range rather than across the whole field, giving three runs during office hours.
The Day-of-Month and Day-of-Week OR Rule
Every pair of cron fields is combined with AND — a job runs when the minute matches AND the hour matches AND the month matches. Every pair except one. When both the day-of-month and the day-of-week fields are restricted, cron switches to OR: the job runs on a day matching either.
The consequence is that 0 0 1 * MON does not mean "midnight on the first of the month, if that day is a Monday". It means "midnight on the first of the month, and also midnight every Monday" — around five runs a month instead of the one or two a year the author intended. This behavior is documented in the crontab manual, it is consistent across Vixie cron and its descendants, and it still catches people who have written cron schedules for years.
The rule only applies when *both* fields are restricted. If either is a wildcard, the other simply decides, which is why the vast majority of expressions behave the way people expect and the trap stays hidden until the day someone writes a schedule using both. This tool detects the condition and says so explicitly rather than leaving you to notice from the run times — though the run times will show it too.
| Expression | Day of month | Day of week | When it fires |
|---|---|---|---|
| 0 0 * * MON | Wildcard | Restricted | Every Monday — weekday decides |
| 0 0 1 * * | Restricted | Wildcard | The 1st — day of month decides |
| 0 0 1 * MON | Restricted | Restricted | The 1st, and also every Monday (OR) |
| 0 0 * * * | Wildcard | Wildcard | Every day |
Questions About This Tool
Why does my expression run more often than I expect?
Most often the day-field OR rule. When both day-of-month and day-of-week are restricted, cron fires on either, not both — so 0 0 1 * MON runs on the 1st and on every Monday. The tool warns whenever an expression depends on this.
Is Sunday 0 or 7?
Both. Standard cron accepts either, which is why a range such as 5-7 is valid and covers Friday to Sunday. Quartz is different again, numbering the week 1-7 with Sunday as 1.
Why is my six-field expression rejected?
Because it is a different dialect. Quartz and Spring add a seconds field at the front and an optional year at the end. Parsing it as five fields would produce a confident, wrong answer, so the tool explains instead.
What timezone are the run times in?
Your browser’s, since that is the only one this page can know. Most servers run in UTC, so check what your scheduler uses before trusting the local times shown here.
What happens at a daylight-saving change?
A job scheduled in the skipped hour does not run that day; a job in the repeated hour may run twice, depending on the implementation. Schedule sensitive jobs outside 01:00 to 03:00, or run the scheduler in UTC.
Does it support @reboot?
No. The @daily, @hourly, @weekly, @monthly and @yearly aliases are expanded to their five-field equivalents, but @reboot has no schedule to compute — it depends entirely on when the machine starts.