Cron Expression Builder

A standard cron expression has five fields, separated by spaces:

* * * * *
│ │ │ │ └─ day of week (0-6, Sunday = 0)
│ │ │ └─── month (1-12)
│ │ └───── day of month (1-31)
│ └─────── hour (0-23)
└───────── minute (0-59)

Each field accepts more than a single number:

• * means every value for that field.
• 5 means exactly that value.
• 1-5 is a range (Monday through Friday in the day-of-week field).
• */15 is a step, here every 15 units.
• 1,15,30 is an explicit list.

The builder maps each field to its own control so you don't have to count positions. As you change a value, the expression updates live, the description rewrites itself, and the upcoming run times recompute. You can also type an expression directly into the input to reverse-engineer something you already have.

Say you want a backup to run at 2:30 AM every weekday. Build it field by field:

• Minute = 30
• Hour = 2
• Day of month = * (any day)
• Month = * (any month)
• Day of week = 1-5 (Monday to Friday)

The result is:

30 2 * * 1-5

The builder reads this back as "At 02:30 on every day-of-week from Monday through Friday" and lists the next runs, e.g. tomorrow at 02:30, the day after at 02:30, skipping the weekend. If you instead wanted it every 30 minutes during business hours on weekdays, you'd use */30 9-17 * * 1-5. Checking the listed run times is the quickest way to catch a mistake before it ships.

Cron expressions show up far beyond the classic Unix crontab:

• Server jobs — log rotation, database backups, cache warming, certificate renewal.
• CI/CD pipelines — scheduled builds, nightly test runs, dependency-update checks.
• Cloud schedulers — serverless functions and managed task runners that trigger on a cron schedule.
• Container orchestration — periodic jobs that spin up a pod on a schedule.
• App-level tasks — sending digest emails, generating reports, pruning stale data.

In each case the underlying syntax is the same five fields, so an expression you build here is portable. Always confirm the timezone the target system uses, since the same expression fires at different wall-clock times depending on whether the scheduler runs in UTC or local time.

A few things trip people up:

• Day-of-month and day-of-week are OR'd, not AND'd. If you set both to specific values (e.g. 0 0 13 * 5), the job runs on the 13th or on every Friday, not only on Friday the 13th. To target one, leave the other as *.
• Sunday can be 0 or 7 in most implementations. Pick one and be consistent.
• */N starts from zero, not from "now". */20 in the minute field fires at :00, :20, :40, not 20 minutes after you save it.
• Steps don't evenly divide every range. */40 minutes fires at :00 and :40, then waits until :00 again, so the gap is uneven.
• No timezone lives in the expression itself. The schedule is interpreted in whatever zone the scheduler is configured for.

The classic cron format has five fields and its smallest unit is one minute, so it cannot express "every 10 seconds." Several modern schedulers extend the format with a leading seconds field, making six fields total:

* * * * * *
└─ seconds (0-59), then minute, hour, day, month, day-of-week

Some systems also add a trailing year field. These are extensions, not part of the original specification, so an expression that works in one scheduler may be rejected by another. Before copying an expression across systems, check how many fields the target expects. A six-field expression pasted into a five-field parser will misalign every value, which is a common source of "my job runs at a weird time" bugs. This builder focuses on the widely-supported five-field standard; if your platform needs seconds, add that field according to its own documentation.