Cron Expression Generator

The Cron Expression Generator turns a schedule you have in your head - "every weekday at 8am", "the first of the month at midnight", "every fifteen minutes" - into the five-field cron expression a scheduler understands. You set the minute, hour, day of month, month and day of week, or start from a preset, and the tool assembles the expression, explains it in plain English, and shows you exactly when it will next fire. It closes the gap between what you want to happen and the terse syntax that makes it happen.

Cron syntax is compact and unforgiving. `0 0 * * 0` runs every Sunday at midnight, while `0 0 0 0 0` is not a schedule at all: day of month starts at 1 and month starts at 1, so the tool rejects it with "day of month value out of range (1-31)". The day-of-month and day-of-week fields interact in a way that surprises almost everyone the first time. Writing an expression by hand and hoping it is right is how a backup ends up running once a year instead of once a night. Building it here, with a live description and a preview of upcoming run times, lets you confirm the schedule before it reaches your crontab.

The expression is built, validated, described and simulated client-side, with no account needed. When you press Show next runs, the page makes a usage check and logs a usage record that includes the expression, so treat the schedule string as something that leaves the page. Copy the finished expression straight into a crontab, a CI pipeline, a Kubernetes CronJob, or any scheduler that speaks standard cron.

As a cron job expression generator, it works from the schedule you want. Say a backup should run at 2am every Sunday: set Minute to 0, Hour to 2 and Day of week to 0, leave the other two fields as *, and the expression reads `0 2 * * 0` with the line "At 02:00 on Sunday (UTC)." Press Show next runs on Monday 14 September 2026 and the first entry is Sun, 20 Sep 2026 02:00 UTC, followed by the next five Sundays. That preview is how a free cron expression generator earns its keep: you see the real dates before the job is deployed.

Validation catches the syntax errors, but it cannot catch the logical ones, and the common logical error is the day-of-month and day-of-week rule: when both are set, cron runs on either match rather than both. The plain-English line does not show this, since `0 0 13 * 5` reads "on the 13th of the month on Friday", but the next run list does: it includes every Friday as well as Tuesday 13 October. Check the run list before trusting a schedule.