0–59
0–23
1–31
1–12 or JAN–DEC
0–7 or SUN–SAT
Common examples
How to use it
01
Type or pick
Click one of the examples, type the whole expression, or fill the five fields separately. Everything stays in sync.
02
Read it in plain English
The description rewrites itself on every keystroke. If it does not say what you meant, the expression does not do what you meant.
03
Check the dates
The next five runs, in your time and in UTC. This is the check that prevents most of the surprises.
The symbols
- *
- Every value in the field. In the minute field it means all sixty.
- ,
- A list of single values: 1,15,30 means those three and nothing else.
- -
- An inclusive range: 1-5 in day of week is Monday to Friday.
- /
- A step: */15 is every fifteen, and 10-50/10 is every ten between 10 and 50.
- JAN, MON
- Three-letter English names, in the month and day-of-week fields.
- 0 and 7
- Both mean Sunday in the day-of-week field. It is not a typo.
The shortcuts
- @hourly
- 0 * * * *
- @daily · @midnight
- 0 0 * * *
- @weekly
- 0 0 * * 0
- @monthly
- 0 0 1 * *
- @yearly · @annually
- 0 0 1 1 *
- @reboot
- On machine start. It is not a time, so it has no next runs.
The shortcuts work in the field above: type @daily and the tool expands it to its five fields.
Scheduling the job is the easy part
The hard part comes afterwards: what happens when the job fails at three in the morning and nobody notices, what happens when it takes longer than its own interval and overlaps itself, and what happens when the server was down at that moment. Cron does not retry, does not alert and leaves no trace unless you build that yourself.
That is exactly the work we do when we automate a process: the scheduled run is one line; the logging, the retries and the alert when something does not add up are all the rest.
Frequently asked questions
What time zone does a cron job run in?
The one belonging to the system that runs it, and that is the problem: almost every server and almost every deployment platform works in UTC. If you write "0 9 * * *" thinking of nine in the morning in Bogotá, on a UTC server that is four in the morning. That is why this tool shows every run in both times and lets you choose how the expression is interpreted.
Why does my job run on days it should not?
Almost certainly the OR rule. When both day of month and day of week are restricted, cron runs if either matches. "0 0 1 * 1" is not "the 1st if it falls on a Monday": it is "the 1st, and also every Monday". To get the intersection you have to leave one as an asterisk and check the other inside your own script.
What is the difference between five and six fields?
The classic crontab format has five: minute, hour, day of month, month and day of week. Quartz — the Java scheduler behind many enterprise tools — adds seconds at the front and sometimes a year at the end, and uses "?" where crontab uses "*". If you paste a six-field expression here, the tool says so rather than misreading it.
How often is "*/7" in the minutes field?
Every seven minutes within each hour, but not every seven minutes end to end: it fires at 0, 7, 14 and so on up to 56, and the next one is 0 of the following hour, four minutes later. The step restarts with every hour. If you need a genuinely constant interval, use a step that divides 60: 2, 3, 4, 5, 6, 10, 12, 15, 20 or 30.
Is my expression sent to a server?
No. Parsing, describing and working out the dates all happen in your browser with ordinary arithmetic. There are no network requests, nothing is stored, and this site uses no tracking cookies.
Do daylight saving changes affect the next runs?
Yes, awkwardly. If you interpret the expression in a zone with daylight saving, the night of the change may contain an hour that does not exist or one that happens twice, and every cron implementation resolves that differently. Here the dates are computed with your browser time zone, so they are a guide; if the job is critical, schedule it in UTC and the whole problem goes away.
Can I use L, W or # ?
Not in ordinary cron. Those wildcards — last day of month, nearest weekday, nth weekday — belong to Quartz and some variants. A Linux crontab does not understand them, so this tool does not accept them either: better to reject them here than to find out in production that your server does not support them.
And if the job fails at three on a Sunday?
Scheduling a run is one line. Someone finding out when it does not happen, being able to retry it, and having a record of it — that is what turns a cron job into a reliable process.
We reply within one business dayBogotá · UTC−5