How to use the cron explainer
- Type or paste a cron expression, or pick one from the presets. The description updates as you type.
- Read the plain-English summary, then check the field breakdown to see exactly which minutes, hours, days and months match.
- Switch between Local time and UTC. Servers and CI systems usually run cron in UTC, so the UTC list is often the one that matches production.
- Copy the description into a code comment or a ticket so the next person does not have to decode the schedule.
The plain-English text comes from the open-source cronstrue library; the breakdown and the next run times are calculated by this page. Both run in your browser.
Worked example
The expression */15 9-17 * * MON-FRI is read as "Every 15 minutes, between 09:00 and 17:59, Monday through Friday".
| Field | Value | Matches |
|---|---|---|
| Minute | */15 | 0, 15, 30, 45 |
| Hour | 9-17 | 9 to 17 |
| Day of month | * | every day |
| Month | * | every month |
| Day of week | MON-FRI | Monday to Friday |
The last run of each day is 17:45, not 17:00, because the hour field includes the whole of hour 17. Starting from Thursday 1 January 2026 at 00:00 UTC, the next runs are 09:00, 09:15, 09:30, 09:45 and 10:00 UTC that same day.
Cron syntax in brief
A standard cron expression has five fields separated by spaces: minute (0-59), hour (0-23), day of month (1-31), month (1-12 or JAN-DEC) and day of week (0-7 or SUN-SAT, where both 0 and 7 mean Sunday). Each field accepts * for every value, single values, lists such as 1,15, ranges such as 1-5 and steps such as */10 or 0-30/5. Shortcuts such as @daily, @hourly and @weekly are expanded to their five-field form.
One rule surprises many people. When both day of month and day of week are restricted, cron runs when either matches. 0 0 13 * 5 therefore runs at midnight on every 13th and on every Friday, not only on Friday the 13th. If either field starts with *, both must match. The page applies this rule and shows a note when it is in effect.
Common mistakes
- Six fields – Quartz, Spring and some cloud schedulers add a seconds field or a year field. Remove it to check the schedule here.
- Wrong time zone – a job set to
0 9 * * *on a UTC server runs at 09:00 UTC, which may be early morning or afternoon where you are. - Backwards ranges –
FRI-MONdoes not wrap around; writeFRI-SAT,SUN-MON. - Impossible dates –
0 0 30 2 *is valid syntax but never runs, because February has no 30th. - Daylight saving time – local times that are skipped when clocks go forward are left out of the list.
Working with epoch values in job logs? The Unix timestamp converter turns them into readable dates.
Frequently asked questions
Does this tool send my cron expression anywhere?
No. The description, the field breakdown and the next run times are all computed in your browser. Nothing is uploaded.
Which cron format does it support?
The standard 5-field format used by Linux cron, crontab files, Kubernetes CronJobs and GitHub Actions: minute, hour, day of month, month and day of week, with names, lists, ranges, steps and shortcuts like @daily.
Why does my expression run on more days than expected?
If both the day-of-month and day-of-week fields are restricted, cron runs when either one matches. For example 0 0 1 * 1 runs on the 1st of each month and on every Monday.
Are the next run times in my time zone?
By default they use the time zone of your device. Switch to UTC to see the times a server running in UTC would use; most cloud schedulers and CI systems use UTC.
Why does a schedule with 6 fields show an error?
Six or seven fields mean a seconds field or a year field, as used by Quartz and Spring. Those are not part of standard cron, so remove the extra fields to check the schedule here.
What does */5 mean in cron?
It means every fifth value of the field, starting at the lowest. In the minute field */5 matches minutes 0, 5, 10 and so on up to 55.