Cron Expression Generator

What cron is

Cron is the time-based job scheduler built into Unix and Linux systems. It runs commands automatically on a schedule — a backup every night, a report every Monday, a cleanup task every hour. The schedule is defined by a cron expression, and that expression is what trips people up.

The five fields

A standard cron expression is five fields separated by spaces, representing minute, hour, day of month, month, and day of week in that order. Each field says when the job may run, and the job runs when all the fields match the current time.

The reference table above shows the allowed range for each. An asterisk means "every" — every minute, every hour, and so on. The classic "every day at 9am" is written as minute zero, hour nine, and asterisks for the rest: 0 9 * * *.

The special characters

Four symbols give cron its flexibility. The comma lists specific values — 0,30 in the minute field means on the hour and on the half hour. The hyphen gives a range — 1-5 in the day-of-week field means Monday through Friday. The slash gives a step — */15 in the minute field means every fifteen minutes.

Combining them expresses quite specific schedules. Weekdays at 9am is 0 9 * * 1-5, which this tool explains in plain English as you type — the reliable way to confirm an expression means what you intend before it goes live.

The traps that catch everyone

Day of week is numbered from zero, and zero is Sunday. This catches people constantly, because it is off by one from how many think of the week. Seven is also accepted for Sunday on many systems, which adds to the confusion.

The most dangerous mistake involves specifying both day of month and day of week. Contrary to intuition, cron treats these with OR logic when both are restricted, not AND. An expression restricting both does not mean "the 1st, but only if it is a Monday" — it means "the 1st, or any Monday". This behaviour surprises almost everyone and is a genuine source of production incidents. Where it matters, restrict only one of the two fields.

Timezone matters

Cron runs in the server's timezone, not yours and not the user's. A job scheduled for 9am runs at 9am wherever the server thinks it is. This becomes a real problem around daylight saving transitions, where a job scheduled in the skipped or repeated hour may run twice or not at all. For anything time-sensitive, know your server's timezone and consider scheduling outside the transition hours.

Testing before you rely on it

An incorrect cron expression fails silently — the job simply does not run when you expected, and you may not notice until something downstream breaks. Reading the plain-English explanation here is a quick sanity check. For critical jobs, it is also worth logging each run so you can confirm the schedule is behaving.

Generated in your browser

Everything is computed locally with nothing transmitted.

Frequently Asked Questions