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.
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.