Cron expressions look cryptic at a glance but follow a strict, learnable structure — five fields, each with its own rules for wildcards and ranges. The single most common source of confusion, though, isn't the syntax within a field; it's how two of the fields interact with each other.
The Five Fields, In Order
A standard cron expression has exactly five space-separated fields, always in this order: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, where 0 means Sunday). Each field independently restricts when the job runs — a job only fires at a moment when every field's condition is satisfied simultaneously, with one important exception covered below.
Why Day-of-Month and Day-of-Week Combine as OR
Every other pair of cron fields is combined with AND logic — the minute and hour fields both have to match for the job to run at that moment. But day-of-month and day-of-week are the one exception: if both fields are restricted (neither is left as a wildcard *), standard cron treats them as an OR instead. An expression like 0 9 15 * 1 (9 AM on the 15th of the month, or on Mondays) runs on both the 15th of every month AND every Monday — not only on days that happen to be both the 15th and a Monday. This OR behavior is easy to miss and is the single most common source of "why did my cron job run on a day I didn't expect" confusion.
Ranges, Lists, and Step Values
Beyond a plain wildcard or specific number, each field supports a few shorthand patterns: a range like 9-17 means every value from 9 through 17 inclusive, a list like 1,3,5 means exactly those three values, and a step like */15 means every 15th value starting from the field's minimum (so */15 in the minute field means :00, :15, :30, :45). These can combine — */15 9-17 * * 1-5 means every 15 minutes, during the 9 AM–5 PM hour range, Monday through Friday.
The Time Zone Trap
Cron itself has no built-in concept of time zone — it simply runs against whatever clock the system executing the job is set to. This becomes a real problem when a job is written and tested on a laptop in one time zone but deployed to a server in another; the "9 AM" the expression describes is 9 AM server time, not 9 AM in the time zone where it was written. Always confirm which time zone the actual execution environment uses before trusting an expression's intended schedule.
Parse Your Expression Instantly
Type any 5-field cron expression and see a field-by-field breakdown plus the next several run times with our free Cron Expression Parser — a fast way to sanity-check a schedule before deploying it.
FAQ
What do the 5 fields in a cron expression mean? In order: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, where 0 is Sunday). Each field can be a specific value, a *, a range like 1-5, a list like 1,3,5, or a step like */15.
What happens when both day-of-month and day-of-week are restricted? Standard cron treats this as an OR — the job runs if either condition is true, not only when both match. This matches the behavior of cron on Linux and most job schedulers.
Are the next run times shown in my local time zone? Yes — they're calculated using your browser's local clock and time zone. If the actual server running this cron job is in a different time zone, its real run times will differ accordingly.
Is my cron expression sent anywhere? No — parsing and the next-run calculation both happen entirely in your browser using JavaScript, so nothing you enter is ever sent to a server.