Cron Expression Builder & Parser — Plain English, Next Runs

Five fields, and one rule that catches everyone

A cron expression is five space-separated fields: minute, hour, day of month, month, day of week. Each accepts a number, a list (1,15), a range (9-17), a step (*/15), or * for every value.

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

This is the one that produces genuine production incidents. When both the day-of-month and day-of-week fields are restricted, cron runs the job when either matches — not when both do.

So 0 0 1 * 1 does not mean "the first of the month, if it is a Monday". It means "the first of the month, and also every Monday" — roughly five times more often than intended. If either field is *, the rule does not apply and behaviour is what you would expect. The explanation above states this explicitly whenever it applies.

Time zones

A cron expression carries no time zone. It is interpreted in whatever zone the scheduler runs in — usually UTC in a container, and usually the machine's local zone on a traditional server. A job that looks like it runs overnight in your zone may be running during business hours for your users. Next run times are shown in your local zone and in UTC for exactly this reason.

Daylight saving makes it worse: in zones that observe it, a job scheduled at 02:30 local may run twice or not at all on the changeover days. Anything that must not double-run should be idempotent, or scheduled in UTC.

Shortcuts

Most implementations accept @yearly, @monthly, @weekly, @daily and @hourly, which are expanded here so you can see what they actually mean. @reboot is deliberately not supported: it is not a schedule, and it does not exist in Kubernetes CronJobs.

A word on frequency

* * * * * runs every minute — 1,440 times a day. That is occasionally what you want and very often a mistake, especially attached to something that takes longer than a minute to finish. A warning appears for schedules that fire more than once a minute's worth of work can absorb.

Questions people actually ask

Which cron dialect does this follow?

Standard five-field crontab — minute, hour, day of month, month, day of week — which is what Linux cron, Kubernetes CronJobs and most schedulers accept. An optional sixth leading field for seconds is supported for Quartz-style expressions.

Why does my day-of-month and day-of-week expression fire more often than expected?

Because when both fields are restricted, cron treats them as OR, not AND. `0 0 1 * 1` runs on the 1st of the month *and* every Monday, not only on a Monday the 1st. This surprises almost everyone the first time, and the plain-English output states it explicitly.

What time zone do the next runs use?

Your local zone, with UTC shown alongside. This matters because cron on a server usually runs in the server's zone, and a schedule that looks like an overnight job locally may be running in the middle of your users' day.