Cron Expression Generator & Tester

What is a cron expression?

A cron expression is five values separated by spaces. Each value answers one question about when, and a job runs at every minute where all five answers are satisfied.

┌───────────── minute        (0 – 59)
│ ┌─────────── hour          (0 – 23)
│ │ ┌───────── day of month  (1 – 31)
│ │ │ ┌─────── month         (1 – 12  or JAN – DEC)
│ │ │ │ ┌───── day of week   (0 – 6   or SUN – SAT, 0 = Sunday)
│ │ │ │ │
30 2 * * 1-5    →  02:30, Monday to Friday

There is no "every 90 minutes" and no "every second Tuesday" in this dialect. Cron matches a calendar pattern; it does not count intervals from a start point. That distinction explains most of the confusion around it.

The five operators

Steps are the operator people misread most often. */15 does not mean "every 15 minutes from now". It means "every value in 0–59 divisible by 15", which is minutes 0, 15, 30 and 45 of every hour. The difference shows up as soon as the range does not divide evenly:

*/20 * * * *   →  minutes 0, 20, 40        (gaps of 20, 20, 20)
*/25 * * * *   →  minutes 0, 25, 50        (gaps of 25, 25, 10)
0 */7 * * *    →  hours 0, 7, 14, 21       (then a 3-hour gap at midnight)

A step can also start partway through: 10-50/10 in the minute field gives 10, 20, 30, 40, 50 and skips minute 0.

How to build a schedule here

1. Start from a preset or type an expression The presets cover the schedules that account for most real cron entries. Both the full expression box and the five individual field boxes stay in sync.
2. Read the plain-English description Generated with the cronstrue library. If it does not describe what you meant, the expression is wrong even though it is valid.
3. Check the next six run times This is the real verification step. A schedule can parse perfectly and still fire at the wrong moment.
4. Switch between UTC and local time Servers and CI runners almost always schedule in UTC, while your intuition is in local time. Comparing both catches off-by-an-hour mistakes before deployment.

The day-of-month and day-of-week trap

This is the single most surprising rule in cron, and it is in the POSIX specification rather than a bug in any particular implementation.

When both the day-of-month and day-of-week fields are restricted, they are combined with OR, not AND.

0 0 13 * 5

Reads like:  "midnight on Friday the 13th"
Actually:    "midnight on the 13th of any month,
              AND midnight on every Friday"

That expression fires roughly 64 times a year, not once or twice. When only one of the two day fields is restricted, the rule does not apply and the schedule behaves as expected.

There is no way to express a true AND in a 5-field expression. The standard workaround is to schedule on the weekday and check the date at the start of the job:

# crontab: every Friday at midnight
0 0 * * 5 [ "$(date +\%d)" = "13" ] && /usr/local/bin/run-job

Note the escaped \%. In a crontab file an unescaped % is treated as a newline in the command, which silently breaks any command containing a date format string.

This page warns you whenever both day fields are restricted, and the calculated run times reflect the real OR behaviour rather than the intuitive one.

Examples that come up repeatedly

The nickname shortcuts @hourly, @daily, @midnight, @weekly, @monthly and @yearly are accepted here and expanded to their 5-field equivalents. @reboot is deliberately not, since it has no calendar schedule to calculate.

Common mistakes

• Assuming */n means "every n from now". It divides the field's range from zero. */40 in the minute field gives minutes 0 and 40, then a 20-minute gap.
• Scheduling on day 31. 0 0 31 * * skips April, June, September and November entirely — seven months a year rather than twelve. For "last day of month" you need a scheduler that supports L, or a job that checks the date.
• Forgetting the server's time zone. Cron uses the system zone unless configured otherwise. A container built from a minimal base image is almost always UTC, so 0 9 * * * is 09:00 UTC, not 09:00 where you live.
• Ignoring daylight saving. On a machine set to a DST-observing zone, a job scheduled at 02:30 can be skipped in spring and run twice in autumn. Scheduling in UTC, or outside 01:00–03:00, avoids the problem.
• Using 7 for Sunday and expecting a range to work. 7 alone is accepted as Sunday by most implementations, but 5-7 is not portable. Write 0,5,6 instead.
• Writing a backwards range. 0 22-4 * * * is rejected by most parsers rather than wrapping around midnight. Split it: 0 22-23,0-4 * * *.
• Unescaped % in the command. Only affects crontab files, but it truncates the command at the percent sign, which looks like the schedule failing.

Use cases

• Validating a Kubernetes CronJob. The schedule field is 5-field cron interpreted in UTC by default, so the UTC view here matches what the cluster will do.
• Setting up a GitHub Actions workflow. on.schedule.cron uses this dialect and always runs in UTC. Confirming next-run times avoids a workflow that fires at 3am local.
• Reviewing an inherited crontab. Paste an existing line to find out what it actually does — particularly useful when both day fields are set.
• Sizing a job's load. The approximate runs-per-year figure makes it obvious when */1 was left in from testing.
• Spreading out scheduled load. Rather than every job at 0 0 * * *, offsetting minutes across jobs avoids a midnight spike. Seeing the exact minutes helps plan that.
• Checking a database backup window. Confirming the schedule falls inside the maintenance window before it runs in production.

Working with timestamps in the logs those jobs produce? The Epoch Converter turns Unix timestamps into readable dates.

Privacy

Parsing, validation, next-run calculation and the plain-English description all run in your browser. No expression is sent to a server, and nothing is stored between visits.