Cron Expression Builder

Cron's five-field syntax is compact but unforgiving, and most people end up looking up "what does 0 9 * * 1 mean again?" every single time. Cron Builder lets you set each field — minute, hour, day of month, month, day of week — and assembles the expression for you, with common schedules available as one-click presets.

It is the helper you reach for when configuring a scheduled job, a backup, or a recurring task: pick "Every Monday at 9 AM" from the presets, or dial in custom values when your schedule is more specific. It also lists an approximate preview of upcoming run dates so you can sanity-check that you built the schedule you intended.

A standard cron expression is five space-separated fields: minute, hour, day of month, month, and day of week. Each accepts a specific numeric range, and four operators apply throughout — an asterisk for every value, a comma for a list, a hyphen for a range, and a slash for a step.

Reading an expression means reading the fields left to right and remembering that they combine as a conjunction, with one exception. The presence of a value in the minute field is what makes a schedule fire at that minute of every matching hour, which is why an expression with an asterisk in the minute field runs sixty times an hour rather than once.

The presets exist because the common schedules are easy to get subtly wrong, and starting from a working expression and editing one field is more reliable than composing from scratch.

The one genuine irregularity in cron is that day of month and day of week are combined with a logical OR rather than an AND when both are restricted. An expression specifying the 1st and Monday fires on the 1st and on every Monday, not only on a Monday that falls on the 1st. This trips up nearly everyone the first time.

Time zones are the other frequent surprise. Cron ordinarily runs in the server's local zone, so a daylight saving transition can cause a job to be skipped or run twice — a job scheduled inside the hour that disappears in spring never fires that day. Scheduling in UTC avoids the problem entirely and is worth doing for anything important.

Two operational habits. Cron will start a second instance of a job whose previous run has not finished, so any job that might overrun needs its own locking. And cron captures output and attempts to mail it, which typically goes nowhere on a modern server, so redirect to a log file explicitly or failures will be silent. Also note that day-of-week numbering and whether seconds are supported vary between implementations, so check the documentation for the specific scheduler you are targeting.