Cron Expression Parser

Cron syntax is five fields of terse punctuation, and misreading one of them means a job runs at the wrong time or not at all. The failure is usually silent, which is why it is worth checking an expression before committing it rather than after.

How to use it

1. Paste a five-field cron expression.
2. It is parsed into a plain description of when the job runs.
3. Everything happens in the page.

The five fields

In order: minute (0 to 59), hour (0 to 23), day of month (1 to 31), month (1 to 12), and day of week (0 to 7, where both 0 and 7 mean Sunday).

Four operators apply to each field. An asterisk means every value. A comma separates a list, as in 1,15. A hyphen gives a range, as in 9-17. A slash gives a step, so */15 in the minute field means every fifteen minutes, and 0-30/10 means at 0, 10, 20, and 30.

The most common mistake here is a bare */5 in the hour field intending every five hours. It runs at 0, 5, 10, 15, and 20, which means the gap between the last run of one day and the first of the next is four hours rather than five. Steps divide the range, they do not repeat at an interval.

Day of month and day of week are combined with OR

This is the trap that catches almost everyone, and it is genuinely counterintuitive.

Every field is normally combined with AND: a job runs when the minute matches and the hour matches and the month matches. The two day fields are the exception. If both are restricted, meaning neither is an asterisk, the job runs when either matches.

So 0 0 1 * 1 does not mean midnight on the first of the month if it is a Monday. It means midnight on the first of the month, and also midnight every Monday. A schedule intended to run twelve times a year runs around sixty-four times.

The rule only applies when both are restricted. If one is an asterisk, the behaviour is the intuitive one. Getting an AND between the two fields is not expressible in cron, and the usual workaround is to schedule on one condition and check the other in the job itself.

Timezones and daylight saving

A cron expression carries no timezone. It is interpreted in whatever zone the daemon is configured for, which on a server is often UTC and on a laptop is local time. The same crontab moved between machines runs at different real times.

Daylight saving makes this worse in two specific ways. When clocks go forward, the skipped hour does not occur, so a job scheduled at 02:30 simply does not run that day. When clocks go back, the repeated hour occurs twice, so a job scheduled at 01:30 may run twice.

Different cron implementations handle this differently, and none of them handle it in a way everybody expects. The reliable answer is to run the daemon in UTC and do any local-time conversion inside the job. Failing that, schedule jobs outside the transition window, which in most jurisdictions means avoiding 01:00 to 03:00.

Variants you will encounter

Six-field expressions add seconds at the front. Quartz, Spring, and several JavaScript libraries use this form, so an expression copied between ecosystems can silently shift by a factor related to the extra field. Count the fields before assuming.

Special strings are shorthand: @hourly, @daily, @weekly, @monthly, @yearly, and @reboot. They are widely supported but not universal, and @reboot in particular behaves differently across implementations.

Quartz also adds L for last, W for nearest weekday, and hash notation such as 6#3 for the third Friday. None of these exist in standard cron, and an expression using them will fail on a Unix crontab.

One operational note that is not syntax: cron does not prevent overlapping runs. If a job scheduled every five minutes takes six, you accumulate concurrent copies until something falls over. Use a lock file or flock.

At a glance

Frequently asked questions

Read more

Timestamps, permissions, subnets, and cron — Four operational primitives with unintuitive semantics, and the specific failures each one causes.

Related tools