Crontab Generator

Cron's five-field syntax has been mostly unchanged since 1975. It's compact, powerful, and almost universally supported — but mistakes are easy and consequences are visible (jobs fire at the wrong time, monitoring goes silent, billing reports get generated twice on DST boundaries). This generator builds correct expressions and explains them in plain English so the next on-call can read your crontab without reaching for the manual.

The five fields

Standard cron syntax: minute hour day-of-month month day-of-week command. Each field accepts:

• A specific value: 0
• A range: 1-5
• A list: 1,3,5
• A step: */15 (every 15)
• A wildcard: *
• Names for months/days: JAN, MON (system-cron only)

Common patterns

• 0 * * * * — top of every hour.
• */5 * * * * — every 5 minutes.
• 0 9 * * 1-5 — 9 AM on weekdays.
• 30 2 * * 0 — 2:30 AM every Sunday.
• 0 0 1 * * — midnight on the first of the month.
• 15 14 1 * * — 2:15 PM on the first of the month.

Pitfalls that cause silent failures

• Day-of-month and day-of-week together. Cron treats both as "OR" — 0 0 1 * 1 fires on the 1st or any Monday. Use one or the other.
• Timezone confusion. Most Linux distros default cron to system time, which may be UTC. Add TZ=America/New_York at the top of the crontab if you want local time.
• DST transitions. A 0 2 * * * job runs zero times when DST springs forward and twice when it falls back. Avoid the 2 AM hour entirely or use systemd timers (OnCalendar=) which handle DST correctly.
• PATH and environment. Cron runs with a minimal environment. Either source profile explicitly or use absolute paths in your commands.
• No output capture. Cron mails output to the user by default. On modern servers without mail, output disappears. Redirect to a logfile: >> /var/log/myjob.log 2>&1.
• Overlapping runs. If the previous instance is still running, cron starts another. Wrap with flock: flock -n /tmp/myjob.lock command.

When to leave cron behind

For modern systems, consider systemd timers (better DST handling, dependency support, retry logic), Kubernetes CronJobs (declarative, observable, version-controlled), or managed schedulers (AWS EventBridge, GCP Cloud Scheduler) where you want SLAs and built-in retries. Cron is still the right tool for simple per-host jobs, but it's not always the best one.

Frequently Asked Questions