Cron Expressions Explained: How to Schedule Anything With Five Fields

Cron expressions look cryptic at first — five fields of numbers, asterisks, and slashes — but they're one of the most compact, widely used ways to schedule a recurring task, and the syntax becomes intuitive once you know what each field controls.

The five fields

A standard cron expression has five space-separated fields, in this order: minute, hour, day of month, month, and day of week. Each field accepts a specific value, a range, a comma-separated list, an asterisk meaning "every," or a step value using a slash.

0 9 * * 1-5 means: minute 0, hour 9, every day of month, every month, weekdays 1 through 5 — in plain English, "every weekday at 9:00 AM."

Reading a few common patterns

1. **"*/15 * * * *"** — every 15 minutes, all day, every day. The slash means "every Nth value starting from the field's minimum."
2. **"0 0 * * *"** — midnight, every day — a common pattern for daily batch jobs or backups.
3. **"0 0 1 * *"** — midnight on the first day of every month.
4. **"30 8 * * 1"** — 8:30 AM, every Monday.
5. **"0 */6 * * *"** — every 6 hours, on the hour.

A mistake that silently schedules the wrong time

Mixing up the day-of-month and day-of-week fields is one of the most common cron errors — since they're both just numbers, it's easy to put a value in the wrong position and get a job that runs on a completely different schedule than intended, without any error being raised. Cron syntax doesn't validate that your intent makes sense; it just executes the fields literally, so a subtly wrong expression fails silently rather than throwing an error you'd notice immediately.

Day of month and day of week both specified

When both the day-of-month and day-of-week fields are set to something other than an asterisk, most cron implementations treat it as an OR condition, not an AND — the job runs if either condition is true, not only when both match. This is a frequent source of confusion, since it's easy to assume specifying both fields narrows the schedule down further, when it actually broadens it.

Time zones are a separate, easy-to-forget problem

A cron job's schedule is evaluated in whatever time zone the server or scheduler is configured to use, which isn't always the time zone you were thinking in when you wrote the expression. A job intended to run at 9 AM local time can run at a very different hour if the server operates in UTC and nobody accounted for the offset — worth double-checking explicitly rather than assuming, especially for anything time-sensitive like a daily report.

Build or read one without guessing

Rather than counting fields by hand or guessing at syntax, use the Cron Expression Generator & Parser to build a valid expression from a simple form, or paste an existing expression to get a plain-English explanation of exactly when it runs. If your scheduled job needs to log or compare timestamps across time zones, the Timestamp Converter converts Unix timestamps to human-readable dates in any timezone.