Crontab Generator

Introduction

A crontab entry is a compact rule for telling a Unix-style scheduler when a command may run. Five short fields cover minute, hour, day of month, month, and day of week. That economy is useful, but it also means one misplaced character can turn a careful maintenance plan into a noisy job that runs far too often.

Cron schedules are easy to overread because the text looks simpler than the matching rules behind it. A line such as 30 9 1 * 1-5 does not automatically mean "09:30 only when the first day of the month is a weekday." In many common cron implementations, restricting both day fields means the job runs when either one matches. Daylight saving transitions add another complication because missing local times never occur and repeated local times can occur twice.

Cron is also more varied than many people expect. Vixie-style and Cronie-style systems support familiar extensions such as named weekdays, named months, and @daily-style macros, while other implementations make different choices about name lists, randomization, flags, or special strings. Environment settings belong on their own lines too, not inside the five-field expression.

A good crontab helper therefore has two jobs. It should build a readable schedule quickly, and it should make the risky parts obvious enough that you pause before pasting the result into a live scheduler.

Technical Details

Cron is minute-based. A standard user entry is five time fields plus a command. A system crontab or an /etc/cron.d style entry adds a username column before the command. Environment settings such as MAILTO or SHELL are separate lines rather than extra schedule fields.

user crontab   = minute hour day-of-month month day-of-week command
system crontab = minute hour day-of-month month day-of-week user command
environment    = NAME=value on its own line

Matching rules stay straightforward until the two day fields interact. Minute, hour, and month must match. If one day field is a wildcard, the other day field carries the restriction. If both day fields are restricted, many widely used cron daemons treat the line as a day-of-month OR day-of-week match. Cronie also documents that missing daylight saving times never match, while repeated times can run twice.

Dialect support varies beyond that core rule set. Named months and weekdays, stepped ranges, and @ macros are extensions rather than a universal minimum. OpenBSD, for example, allows month and weekday names but does not allow ranges or lists of names, while Cronie accepts those forms. That is why a line that looks ordinary on one host can still need a portability check on another.

This generator deliberately stays inside a conservative subset that covers many everyday jobs. It validates numeric ranges, comma lists, inclusive ranges, wildcard steps such as */5, stepped ranges such as 1-10/2, three-letter month and weekday names, and six macros: @reboot, @hourly, @daily, @weekly, @monthly, and @yearly.

The validator does not cover every cron dialect. Seconds fields, year fields, L, W, #, ?, tilde randomization, @annually, @midnight, and daemon-specific flags are outside its supported subset. Parsing is intentionally narrow as well: it reads the first non-blank line, handles a macro line or a five-field schedule, and guesses a system-crontab username only when a sixth token looks like a username.

The command text is intentionally passed through as typed. Cron manuals note that an unescaped % in the command can be treated as a newline and standard input separator, so a schedule that looks valid at the field level can still need command-level quoting or escaping review on the target host.

Everyday Use & Decision Guide

For a fast first pass, use Preset when the rhythm is familiar or paste an existing job into Parse line when you are repairing rather than inventing. Keep each field in Simple mode unless the Advanced builder makes a list, range, or step easier to read. That keeps the schedule close to ordinary cron syntax instead of turning it into a control-heavy exercise.

• Enter Command early. The schedule can look complete while the copied line is still missing the thing you actually want to run.
• Treat Schedule Overview as the main review surface. It shows every field, the rendered expression or macro, the optional user, and the final Full line that is ready to copy.
• Open Run Profile when you want a plain-language checklist of the current state, including validation status, timezone notes, user mode, and warning messages.
• Use JSON, CSV, or DOCX export when you need documentation or handoff notes. Those views keep the supporting context even when it is not part of the copy-ready line.

User is the only advanced field that changes Full line. MAILTO, SHELL, PATH, TZ, and Comment stay as supporting context in the summary, JSON payload, and DOCX export. If you need them in a real crontab, add them as separate lines or confirm the target scheduler's documented format first.

If a warning banner appears, stop there. The most important one is the dual day-field warning because it usually means the schedule is broader than it looks. The other easy miss is a blank command. The page allows it so you can draft the timing first, but that is a draft state, not a finished job.

The safest handoff is a copied Full line that still reads correctly without any surrounding explanation, followed by a harmless test command on the target host so you confirm the real cron dialect, user context, and timezone behavior before the live job matters.

Step-by-Step Guide

1. Choose a Preset for a common rhythm or paste one existing entry into Parse line if you want to edit a real job.
2. Fill Minute, Hour, Day of Month, Month, and Day of Week. Switch only the fields that need the Advanced builder.
3. Enter Command, then add User only if you are preparing a system-style line rather than a user crontab entry.
4. Open the advanced panel for MAILTO, SHELL, PATH, TZ, or Comment if you want them captured in notes or exports.
5. Review Schedule Overview and read every warning or red validation message before copying.
6. Check Run Profile or JSON if you need a durable record, then copy or export only after Full line matches what you actually intend to install.

Interpreting Results

The most important output is the generated line itself. The plain-language summary is there to catch mental slips, not to replace the actual cron text. If the prose and the tokens feel inconsistent, trust the tokens and correct the fields before you copy anything.

A clean result here means the line is syntactically valid inside the tool's supported subset. It does not certify target-host portability, command quoting, macro support, or timezone behavior. Review named ranges, special macros, percent signs, and any separate environment lines against the scheduler that will actually run the job.

Worked Examples

Weekday report at 09:30

Set Minute to 30, Hour to 9, leave Day of Month and Month as *, set Day of Week to 1-5, and enter a report command. The generated line becomes 30 9 * * 1-5 /usr/local/bin/report, and the summary should read as a weekday-only schedule.

Nightly backup from a preset

Choose the daily midnight preset and add /usr/local/bin/backup as the command. The result is 0 0 * * * /usr/local/bin/backup. This is a good example of when the preset is faster than typing the same common schedule by hand.

A line that looks narrower than it is

Enter 30 9 1 * 1-5 with any command. The page warns because both day fields are restricted. On many common cron systems that means the job runs at 09:30 on the first day of the month, plus every weekday at 09:30. The warning is doing real work here, not just adding noise.

A reboot task in system-crontab style

Select @reboot, set User to root, and enter /usr/local/bin/bootstrap. The copied line becomes @reboot root /usr/local/bin/bootstrap. If you also need mail routing or a custom shell, those belong on separate environment lines rather than inside that one line.

FAQ:

Glossary:

Crontab

A text table of scheduled commands read by a cron daemon.

Cron expression

The five scheduling fields that describe when a command is eligible to run.

Macro

A shorthand schedule such as @daily or @reboot that replaces the five time fields.

System crontab

A cron file that includes a username column before the command so the daemon knows which account should run it.

Environment line

A separate NAME=value line that changes command environment settings without changing the time fields.

Wildcard

The * token, meaning every allowed value for that field.

References:

• crontab(5) - Linux manual page, Linux man-pages project.
• crontab(5) - OpenBSD manual pages, OpenBSD.
• crontab(5) - Debian Manpages, Debian.