How to use the cron expression generator and explainer
- Type or paste a cron expression with five fields, or pick a preset such as Daily or Weekly and set the time, the days and the day of the month. The expression and the five field boxes stay in step.
- Read the plain English line. If the expression is invalid, the message names the field and the value that failed, so you can fix that one part.
- Choose a time zone offset. Run times are always computed on a fixed UTC offset, and UTC is the default. Optionally enter a start date and time, otherwise the current time is used.
- Check the next five run times, then press Copy expression and paste it into your crontab or scheduler.
Worked example
The expression 0 12 13 * 5 has both a day of month (13) and a day of week (Friday). Classic cron runs the job when either one matches, so it fires at noon on every 13th and at noon on every Friday. Counting after October 1, 2026 in UTC, the first five runs are October 2, October 9, October 13, October 16 and October 23, all at 12:00. October 13, 2026 is a Tuesday, so it appears only because of the day of month field.
The expression 0 0 29 2 * runs at midnight on February 29. Counting from January 1, 2026, the next runs are February 29, 2028 and February 29, 2032. A year such as 2100 is divisible by 100 but not by 400, so it has no February 29 and the tool skips it.
The five fields
A classic cron expression has five fields separated by spaces, in this order: minute (0 to 59), hour (0 to 23), day of month (1 to 31), month (1 to 12 or JAN to DEC) and day of week (0 to 7 or SUN to SAT, where both 0 and 7 mean Sunday). Each field accepts these forms:
- An asterisk (*) matches every value in the field.
- 5,10,20 is a list of values.
- 9-17 is an inclusive range, and MON-FRI works with names.
- */15 or 0-30/10 is a step: every 15th value, or every 10th value between 0 and 30.
When both day fields are set
Day of month and day of week do not combine the way the other fields do. In classic Vixie style cron, when both fields are restricted (neither starts with an asterisk), the job runs when either one matches. When one of them starts with an asterisk, such as */2, both conditions must hold. This is a common source of surprises, which is why the page states the rule in the explanation whenever it applies and why the run list is worth checking before you rely on a schedule.
How run times are computed
The tool walks the calendar one day at a time using plain date arithmetic. For each day it checks the month, the day of month and the day of week, then lists the matching hours and minutes in order, and it keeps going until it has five runs that are strictly after your start time. Month lengths and leap years are handled by the calendar, so a job set for the 31st skips short months and a job set for February 29 waits for the next leap year. If nothing is found within about nine years, the page says so, which happens for a date such as February 30.
Which cron this covers
This tool covers the classic five field form, plus the aliases @yearly, @annually, @monthly, @weekly, @daily, @midnight and @hourly. Cron implementations differ. Quartz style expressions add a seconds field, an optional year, and characters such as ? L W and #. AWS EventBridge schedules, Kubernetes CronJobs and the schedulers of hosted platforms each have their own details, such as different day of week numbering or time zone handling. Expressions with six or seven fields, and @reboot, are rejected with a message instead of being guessed. Confirm the exact rules in the documentation of the system that will run the job. See also the chmod calculator for the script permissions and the Unix timestamp converter for turning run times into timestamps.
Assumptions and limits
- Run times use a fixed UTC offset that you pick. Daylight saving changes are not applied, so a job on a local clock that observes daylight saving may run an hour earlier or later in the real world than the list shows.
- Seconds are ignored. Cron has minute resolution, and the next run is always strictly after the start minute.
- The either or rule for day of month and day of week follows classic Vixie cron. A field that starts with an asterisk counts as unrestricted. Other implementations may differ.
- The explanation is a reading aid. It does not know your system, so check the schedule on the machine that runs the job. Everything is computed in your browser, and nothing is sent or stored.
Frequently asked questions
What does */15 mean in a cron expression?
A step of 15 over the whole range of that field. In the minute field it means 0, 15, 30 and 45, so the job runs four times an hour. In the hour field it means every 15 hours counted from 0, which is 0 and 15. The step always restarts at the beginning of the range, not at the time you saved the job.
Why does my job run on days I did not expect?
The most likely cause is setting both a day of month and a day of week. In classic cron that means the job runs when either one matches, so 0 12 13 * 5 runs on every 13th and on every Friday. To run only on Friday the 13th you need a different approach, such as running on Fridays and checking the date inside the script.
Is 0 or 7 Sunday in the day of week field?
Both. The classic form accepts 0 through 7 so that either habit works, and this tool folds 7 into 0. Names also work, so SUN, MON and so on are fine. A range such as 5-7 means Friday, Saturday and Sunday.
Can I paste an expression with seconds or a year?
Not here. A six or seven field expression is the Quartz style, and this tool explains only the classic five field form. It rejects longer expressions and says how many fields it found, so you can remove the extra fields or use a tool made for that scheduler.
Why does the list show a different time than my server?
The list uses the fixed UTC offset you chose, with no daylight saving. If your server uses UTC, leave the offset at UTC. If it uses a local zone, pick the offset that applies on the date you care about and expect a one hour difference across a clock change.