How to read a cron expression
Cron is the scheduler built into Linux and macOS, and its five-field syntax has spread to Kubernetes CronJobs, GitHub Actions, CI systems and most cloud schedulers. A cron expression packs a whole schedule into one short line, such as 30 2 * * 0 for 02:30 every Sunday. It is compact, but easy to misread, and a wrong schedule usually only shows itself when a backup did not run.
This parser explains any standard five-field expression in plain English, shows how each field was understood, and lists the next five times it will fire in your local time, so you can check a schedule before you deploy it.
How to use it
- Type or paste a cron expression with five fields separated by spaces.
- Read the explanation and the field breakdown to confirm each part means what you intended.
- Check the next five fire times. They are computed in your browser's local time zone.
- If a field is invalid, the tool names the field and the reason, such as a value outside its allowed range.
Example: every 15 minutes during office hours
*/15 9-17 * * 1-5
At every 15 minutes, hours 9, 10, 11, 12, 13, 14, 15, 16, 17, on every day-of-month, in every month, on day-of-weeks Mon, Tue, Wed, Thu, Fri.
Note the last run of the day: hour 17 is included, so the job also fires at 17:00, 17:15, 17:30 and 17:45. To stop at 17:00 sharp you need a second line or the range 9-16.
The five fields
In order, the fields are minute (0–59), hour (0–23), day of the month (1–31), month (1–12 or JAN–DEC) and day of the week (0–6 or SUN–SAT, where both 0 and 7 mean Sunday). Each field accepts * for every value, a single number, a range such as 1-5, a list such as 1,15,30, and a step such as */10 or 0-30/5.
A step counts from the start of its range, not from the moment you saved the job. */7 in the minute field fires at minutes 0, 7, 14 and so on up to 56, then again at 0, so the gap across the hour is only four minutes.
The day-of-month and day-of-week trap
When both day fields are restricted, cron fires when either one matches, not both. 0 0 1 * 1 runs at midnight on the 1st of every month and also every Monday. Many people expect it to mean the first of the month only when that day is a Monday, and cron cannot express that on its own. This tool follows the real cron rule: a day field that starts with * counts as unrestricted, and the explanation says or when the rule applies.
Time zones and daylight saving
Classic cron runs in the server's local time zone, while many cloud schedulers default to UTC. On days when clocks change, a job scheduled between 02:00 and 03:00 can be skipped or run twice. Schedule important jobs outside that window, or run the scheduler in UTC.
Questions
Does this support seconds or years?
No. It parses the standard five fields. Quartz and some frameworks add a seconds field in front and sometimes a year at the end; remove those before pasting.
What about @daily and @reboot?
Those are shortcuts some cron versions accept. @daily equals 0 0 * * *, @hourly equals 0 * * * *, and @weekly equals 0 0 * * 0. @reboot has no time and cannot be expressed in fields.
Why does my job run at the wrong hour?
Usually the server's time zone differs from yours. Check it with timedatectl or date on the machine, and remember that containers often run in UTC.