Cron expression explainer
Type a standard 5-field cron expression to read it in plain English and see when it will next run.
tool 03 of 12 []
all shortcuts ?
| Field | Allowed |
|---|---|
| minute | 0-59 |
| hour | 0-23 |
| day of month | 1-31 |
| month | 1-12 or JAN-DEC |
| day of week | 0-7 or SUN-SAT (0 and 7 are Sunday) |
How to use it
- Enter five space-separated fields: minute, hour, day of month, month, day of week.
- Each field accepts a number, a list (1,15), a range (1-5), a step (*/10 or 0-30/5) or * for every value. Month and weekday names such as JAN and MON work too.
- The explanation updates as you type. Below it you will see the next five run times, in UTC or in your local time zone.
- Shortcuts @hourly, @daily, @weekly, @monthly and @yearly are understood.
Examples
Select an example to load it into the tool.
- Every 15 minutes
*/15 * * * * - Weekdays at 9:30
30 9 * * 1-5 - First of the month, midnight
0 0 1 * * - Day 13 or Friday
0 0 13 * 5 - Quartz (6 fields, unsupported)
0 0 12 * * ?
Frequently asked questions
Which cron dialect does this support?
Standard Unix/Vixie cron with five fields, plus the @hourly style shortcuts. Quartz, Spring and AWS EventBridge crons have different fields (seconds, years, ? and L or W characters) and are rejected with a clear message rather than guessed at.
What happens when both day-of-month and day-of-week are set?
In standard cron the job runs when either field matches, not both. 0 0 13 * 5 therefore runs on every 13th and on every Friday. As in Vixie cron, a field that starts with * (such as */2) does not count as set for this rule, so 0 0 */2 * 1 runs only on odd-numbered days that are Mondays. The explanation says which rule applies.
Which time zone does my server use?
Cron daemons use the server's local time zone unless configured otherwise, and some schedulers always use UTC (GitHub Actions schedules do) and Kubernetes CronJobs follow the controller's time zone unless spec.timeZone is set. Check your platform and pick the matching option above.
Why does */7 behave oddly?
Steps restart at the start of each range. */7 in the minute field means 0, 7, 14, 21, 28, 35, 42, 49, 56 and then 0 again at the next hour, so the gap between 56 and 0 is only 4 minutes.
Does it handle daylight saving time?
Local-time run times are computed with your browser's time zone rules. Runs that land in a repeated hour are marked, and runs in a skipped hour do not appear. Real cron daemons differ on how they treat skipped or repeated hours, so schedule important jobs in UTC when possible.