Use the free Cron Next Run Calculator below: your data never leaves your browser — all work happens on your device, and nothing is uploaded to any server.
What a Cron Expression Is
Cron is the classic scheduler on Unix systems, and its expression format has spread to cloud schedulers, backup tools, and automation platforms. A cron expression is five fields separated by spaces: minute, hour, day of the month, month, and day of the week. Each field says when a job may run, and the job runs when all the fields agree. The expression “0 9 * * MON-FRI” means 9:00 in the morning, Monday to Friday, every week.
The format is compact and powerful, but it is easy to get wrong. A single field in the wrong position can move a job from daily to monthly, or from weekdays to weekends. Worse, the mistake often stays silent: the job simply runs at the wrong time, or never runs, and nobody notices until a backup is missing or a report never arrives. The tool above removes that guesswork by showing the next ten run times for any expression, in your local time.
How to Use the Tool
Type a five-field expression and press Find next runs. A table appears with the next ten runs, starting from now, or from the optional start date and time if you set one. The start option is handy for checking a future change: set it to next Monday and see exactly when the new schedule would first fire. Preset buttons fill in common schedules, every minute, daily at midnight, and weekdays at 9:00, so you can compare them at a glance.
Every field supports the standard forms. A star means every value. A list like “1,15” means those values only. A range like “9-17” means every value in between. A step like “*/15” means every fifteenth value, and “9-17/2” means every second value inside the range. Months and weekdays accept names as well as numbers: JAN to DEC, SUN to SAT. For weekdays, both 0 and 7 mean Sunday, following the classic convention.
The Day-of-Month Trap
The trickiest rule is how the two day fields interact. When one of them is a star and the other is restricted, the restricted one decides, which is what most people expect. But when both are restricted, cron runs when either matches, not when both match. So “0 0 1 * MON” runs on the first of the month and on every Monday, not only on Mondays that are the first of the month.
This surprises almost everyone the first time, and it is the cause of many “why did this run today?” mysteries. The calculator follows the classic rule, so if your expression restricts both day fields, the table will show the combined schedule and the surprise disappears before it reaches production. If you truly need both conditions at once, put one of them inside the job itself, for example by checking the date in the script.
Time Zones and Daylight Saving
Cron runs in the time zone of the machine or service that executes it, and the calculator shows times in your browser’s local time, which matches what you see on your own machine. If your server lives in another time zone, translate before you trust the table: a job set for 9:00 server time may be 10:00 or 8:00 for you, and the gap changes when daylight saving starts or ends.
Daylight saving itself creates two edge cases. On the day clocks jump forward, times in the skipped hour never occur, so a job scheduled then simply does not run that day. On the day clocks fall back, times in the repeated hour occur twice, so a job scheduled then may run twice. Neither is a bug in your expression; both are consequences of local time. For jobs that must run exactly once a day, scheduling them away from the 2:00 hour avoids both problems.
Common Schedules, Decoded
Some schedules appear everywhere, and it helps to recognize them. “* * * * *” runs every minute, which is rarely what you want and can overload a system if the job is slow. “*/5 * * * *” runs every five minutes. “0 * * * *” runs at the top of every hour. “0 0 * * *” runs daily at midnight. “0 0 * * 0” runs weekly on Sunday at midnight. “0 0 1 * *” runs monthly on the first. “0 9 * * 1-5” runs weekdays at nine.
When writing a schedule, prefer the simplest form that says what you mean, and add a comment above it in your crontab stating the intent in words, like “weekdays at 9, for the morning report”. The next person to read it, quite possibly you in six months, will be grateful, and the calculator gives you the wording to check: if the table does not match the comment, the expression is wrong, not the comment.
Testing Before You Deploy
Before putting a new schedule live, run it through the calculator from several start points: now, the end of the month, and a date near a daylight-saving change.
Also remember that cron expressions describe when to start a job, not how long it may run. A job that takes longer than its interval will overlap with its next run unless you prevent it with a lock file or a scheduler that skips overlaps.
Related tools
- Calculadora de Proxima Ejecucion de Cron (Spanish version)
- JavaScript Minifier
- JavaScript Beautifier