Cron Translator

Next 10 Runs

What a cron translator does

Cron expressions are compact, but the syntax is cryptic enough that even people who write them daily double-check before saving. 0 */6 * * 1-5 runs every 6 hours on weekdays, but it takes a moment of staring to confirm that. This tool translates cron expressions in both directions. Paste an expression to read it in plain English, or build one visually using the field editors and preset buttons above.

It also previews the next 10 runs in your local timezone. That is the fastest way to catch the two most common cron mistakes: a daily job that is actually running at UTC midnight instead of yours, and a "weekly on Monday" rule that quietly fires twice because day-of-month and day-of-week are both set.

How a cron expression is structured

Standard cron uses five space-separated fields, read left to right.

┌──────────── minute       (0-59)
│ ┌────────── hour         (0-23)
│ │ ┌──────── day of month (1-31)
│ │ │ ┌────── month        (1-12, JAN-DEC)
│ │ │ │ ┌──── day of week  (0-6, SUN=0)
│ │ │ │ │
* * * * *

Each field accepts five kinds of value. A specific number like 5 means exactly 5. A wildcard * means "every value". A list such as 1,3,5 fires on each item. A range like 1-5 means 1 through 5 inclusive. A step like */15 means every 15 units starting from the lowest value of the field, so */15 in the minute field fires at :00, :15, :30, and :45.

Some cron implementations also accept shorthand like @hourly, @daily, @weekly, @monthly, and @yearly. This tool translates standard five-field Unix cron. If you are working with six-field Quartz or Spring cron, the leftmost field is seconds and the dialect differs enough that you will want a parser built specifically for those.

Common cron patterns

These cover most of what you will actually write in the wild. Each one works in standard Unix cron, Linux crontab, and scheduler services like GitHub Actions, AWS EventBridge, and Kubernetes CronJobs.

Cron gotchas that trip everyone up

Day-of-month and day-of-week are combined with OR, not AND

If you write 0 0 15 * 1 expecting "midnight on the 15th, but only if it is a Monday", cron will actually fire on every 15th and every Monday. The two day fields are unioned, not intersected. The workaround is to use one field or the other, not both, unless the union behavior is what you want.

Every cron service has its own default timezone

A schedule like 0 9 * * * means 9 AM in whatever timezone the scheduler uses, which is not always what you would expect. Classic Linux crontab uses the server's local timezone. GitHub Actions always runs in UTC. AWS EventBridge rules default to UTC but support overrides. Always check. If you need 9 AM in a specific zone regardless of where the server lives, most modern schedulers accept a prefix like CRON_TZ=America/New_York 0 9 * * *.

Step values do not always behave the way you expect

*/15 in the minute field is intuitive: it fires at :00, :15, :30, and :45. But */15 in the hour field only fires at hour 0 and hour 15, because hour 30 does not exist. Steps reset at the start of each parent cycle. If you want something like "every 15 hours" across a longer window, cron cannot express it directly.

There is no sub-minute precision in standard cron

If you see * * * * * * with six fields, or a leading seconds value like 0/30, you are looking at Quartz or Spring cron, not Unix cron. Standard Unix cron runs on a one-minute heartbeat at the earliest. For anything finer, you need a different scheduler or a long-running process that sleeps between executions.