Cron Expression Generator

The situation that brings people here is nearly always the same: you have inherited an expression like 0 3 * * 1-5 from a crontab, a Kubernetes CronJob manifest, a GitHub Actions schedule or a Quartz configuration, and you need to know what it actually does before you touch it. Five asterisks and a couple of numbers are not self-documenting, and getting it wrong means a job that silently never fires or one that fires far more often than anyone intended.

Be clear about what this page is, because plenty of tools called "cron generator" are something else. This is a parser and explainer, not a form-based builder. You give it an expression; it gives you a sentence describing the schedule, a labelled breakdown of every field, and — the part that actually settles arguments — the next six concrete run times computed in an IANA timezone of your choosing, defaulting to UTC. Reading "at 03:00 on weekdays" is reassuring; seeing six real timestamps is proof.

Five fields, six fields, seven fields and the @shorthands

Classic Unix cron takes five fields, in this order:

• minute (0–59), hour (0–23), day of month (1–31), month (1–12), day of week (0–6, Sunday is 0)

Quartz, Spring and several other schedulers prepend a seconds field, giving six, and some append a year field, giving seven. All three shapes are accepted here. When six or seven fields are supplied and the sixth looks like a schedule field rather than a command, it is read as part of the expression; otherwise everything past field five is treated as the command. Fewer than five fields or more than seven is rejected with an explanation rather than a guess.

The shorthand aliases are expanded before parsing, and the expansion is reported so you can see what you actually asked for:

• @hourly → 0 * * * *
• @daily and @midnight → 0 0 * * *
• @weekly → 0 0 * * 0 (midnight on Sunday)
• @monthly → 0 0 1 * * (midnight on the 1st)
• @yearly and @annually → 0 0 1 1 * (midnight on 1 January)

@reboot is deliberately not supported, and that is not an oversight. It is not a schedule at all — it tells cron to run the command once when the daemon starts. There is no recurrence to describe and no next run time to compute, because the answer depends on when the machine next boots.

Within a field you can use a single value (5), a list (1,15,30), a range (9-17), a step (*/15, meaning every fifteenth unit), or a step over a range (9-17/2). Month and day-of-week also accept three-letter names such as JAN and MON.

The day-of-month / day-of-week trap

This is the one behaviour that surprises experienced engineers, and it is worth reading twice. Cron fields are normally ANDed together: 30 4 * * * means minute 30 and hour 4. But day-of-month and day-of-week are ORed when both are restricted to something other than *.

So 0 0 13 * 5 does not mean "midnight on Friday the 13th". It means midnight on the 13th of every month, and also midnight on every Friday — roughly five times as many runs as intended. The correct reading of a Friday-the-13th schedule cannot be expressed in standard cron at all; you have to restrict one field and test the other inside the job itself.

The rule in full: if either day field is *, the other one simply applies. If both are restricted, the job runs when either matches. This behaviour is specified in POSIX and implemented by Vixie cron, so it is not a quirk of one distribution. Quartz sidesteps it by requiring ? in whichever day field you are not using.

The six upcoming run times are the reliable way to catch this. If you expected a schedule to fire monthly and the list shows entries a few days apart, you have hit the OR rule.

Timezones, daylight saving and where the expression runs

A cron expression carries no timezone information. It is interpreted by whatever is executing it, which might be the server's local zone, the CRON_TZ or TZ variable set at the top of the crontab, the timeZone field of a Kubernetes CronJob, or UTC. GitHub Actions and most managed schedulers use UTC unconditionally. Choosing the wrong zone here produces six perfectly computed timestamps that describe a schedule nobody is running.

Daylight-saving transitions are where this becomes concrete. In a zone that observes DST, a job scheduled at 0 2 * * * will be skipped on the spring-forward day, because 02:00 never occurs, and may run twice on the autumn day when 02:00 happens twice. If a job must run exactly once a day, schedule it outside the 01:00–03:00 window or run it in UTC.

Run times are shown as YYYY-MM-DD HH:MM:SS in the zone you selected, so they are directly comparable with what your scheduler will log.