Toolivaro

Free Cron Builder

Build and validate five-field cron expressions with a human-readable description and honest next-run times.

The cron builder assembles five-field crontab expressions — minute, hour, day-of-month, month, day-of-week — the syntax every cron daemon on Linux and Unix reads. Fill the five fields with the notation cron actually accepts: a wildcard, a single value, a range like 9-17, a step like */15 or 0-30/5, or a comma list, plus the month and weekday names cron itself recognizes (jan-dec, sun-sat, and even ranges like mon-fri and jan-mar). Each field is validated against its real bounds — minutes 0–59, hours 0–23, days 1–31, months 1–12, weekdays 0–7 with 7 meaning Sunday exactly as the man page says — and invalid input is rejected with a message that says what is wrong, never silently "fixed". From the parsed specification the tool derives three things that matter: the canonical expression to paste into crontab, a plain-language description of when the job runs, and the next real run time, computed minute-by-minute against the daemon's actual matching rules. That last step is where most builders lie, and this one is careful in three ways. The next run is computed in your browser's local timezone, and the page says so, because a cron daemon on a server runs in the server's timezone. The classic OR rule is honored: when both day-of-month and day-of-week are restricted, cron fires when EITHER matches — surprising, documented, and shown in the description. And impossible dates are reported honestly: a job for 31 February finds no next run within the 366-day horizon and tells you so instead of looping forever. Everything is computed locally — nothing you type is uploaded or stored. Use it when you are scheduling a backup, a build, a report, or a database job and want the expression right before it goes into production.

Processed locally in your browser

How is the result calculated?

A nightly backup on weekdays

Your application database needs a backup every weekday at 2:30 in the morning. Set minute to 30, hour to 2, day-of-month to *, month to *, and day-of-week to 1-5 (Monday through Friday). The builder returns the expression 30 2 * * 1-5, describes it as "At 02:30 on weekdays (Mon–Fri)", and shows the next actual run time computed from the current clock — so the job you paste into crontab is exactly the job you meant.

Example input and output
Input Value
minute 30
hour 2
dom *
month *
dow 1-5
Result 30 2 * * 1-5 — At 02:30 on weekdays (Mon–Fri)

What is the formula and its assumptions?

The five-field crontab format

minute hour day-of-month month day-of-week

Formula terms
Symbol Meaning
minute 0–59
hour 0–23
day-of-month 1–31
month 1–12, or jan…dec
day-of-week 0–7 (0 and 7 are Sunday), or sun…sat

Each field accepts *, a value, a range a-b, a step /n, or a comma list. This is the format from crontab(5); the tool implements no extensions beyond it.

Next-run matching

next = first time ≥ now where every field matches

Formula terms
Symbol Meaning
matches the minute, hour, month, and day all fall in their fields’ value sets, with cron’s OR rule for the two day fields
OR rule when day-of-month AND day-of-week are both restricted, a day matches if either field matches — the documented Vixie-cron behavior

Computed in the browser’s local timezone; the page states this, because a server-side daemon uses the server’s timezone.

What are the most common mistakes?

  • Restricting both day-of-month and day-of-week and expecting AND semantics — cron ORs them, and the tool models that.
  • Trusting a next-run time without checking the timezone — the tool uses your local timezone and says so.
  • Using a 6-field expression with seconds and expecting a standard crontab to accept it — the portable format is five fields.

What are the assumptions and limitations?

  • Five-field crontab format only — no seconds field, no @yearly-style aliases in the expression itself.
  • Names (jan, mon) work as values and named ranges; steps and lists use numbers.
  • Next-run computation uses your browser’s local timezone and a 366-day horizon.

Where do the numbers come from?

Last reviewed August 12, 2026 · Version 1.0.0 · Toolivaro does not guarantee external content.

Frequently asked questions

What does the OR rule mean for day-of-month and day-of-week?

When both fields are restricted — say day-of-month 1 and day-of-week 5 — cron runs when EITHER matches, so the job fires on the 1st of the month AND on every Friday. This surprises most people, and it is exactly how Vixie cron and its descendants behave. The tool honors it in the next-run computation and states it in the description.

What timezone does the next-run calculation use?

Your browser’s local timezone. A cron daemon runs in the server’s timezone, which may be UTC or anything else — the page says the timezone explicitly, and you should compare it to the server that will run the job before trusting the printed time.

Why is 7 accepted for Sunday, and is 0 also Sunday?

crontab(5) defines day-of-week as 0–7, where both 0 and 7 mean Sunday; 7 is a legacy form some systems accept. The tool accepts both and normalizes them to the same value for matching.

Where is the seconds field?

The standard five-field format has no seconds field — the smallest unit is the minute. Some tools (like Quartz and some Node libraries) extend cron with seconds, but those extensions are not portable across daemons, so this builder sticks to the portable five-field format.

What happens with impossible dates like 31 February?

Cron simply never fires them. The tool computes the next run over a 366-day horizon and, when no run exists — as with 31 February — reports that honestly instead of showing a date that will never come.

Part of Time, date, and scheduling tools

Found a mistake or have a correction? Report it — we review every correction.

Was this helpful?

Reviewed by the Toolivaro editorial team per our methodology Methodology · Editorial policy