Cron Expression Parser

A standard cron expression is five space-separated fields, in order: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where both 0 and 7 usually mean Sunday depending on the implementation). Each field independently says which values of that unit the job should run on, and the job fires only when the current time matches all five fields — with one deliberate exception.

When both day-of-month and day-of-week are restricted to something other than *, most cron implementations (including the classic Vixie cron behind crontab(5) on Linux) treat those two fields as OR, not AND. That means 0 9 1 * MON — meant by a newcomer to read as "9am on the 1st, if it's a Monday" — actually fires on every 1st of the month AND every Monday. If you need a genuine AND (only the 1st when it also happens to be a Monday), you have to leave one of the two fields as * and add that logic in the job itself.

Within any single field, a comma lists specific values (1,15,30 in the minute field fires at :01, :15 and :30), a hyphen defines an inclusive range (9-17 in the hour field covers 9am through 5pm), and a slash defines a step, almost always combined with a range or the wildcard (*/15 means every 15 units, starting from the field's minimum). These combine: 0 9-17/2 * * 1-5 fires on the hour, every 2 hours from 9am to 5pm, Monday through Friday.

Most schedulers also accept shorthand presets as a convenience over spelling out five fields — @daily (equivalent to 0 0 * * *), @hourly, @weekly, @monthly and @yearly are the common ones, plus the non-standard @reboot for "run once at startup" rather than on any calendar schedule at all.

Cron traditionally schedules against the system clock's local timezone, which means a job scheduled for 2:30am can behave strangely on the two nights a year daylight saving time changes: during a "spring forward" transition, the clock skips straight from 1:59am to 3:00am, so a job scheduled inside that missing hour simply never fires that day. During "fall back", the clock repeats an hour, so a job scheduled inside it can fire twice.

Servers and containers increasingly run cron in UTC specifically to sidestep this — UTC never observes daylight saving time, so a UTC-scheduled job always fires exactly once, at a consistent offset from any timezone. If a production job unexpectedly runs twice or gets silently skipped once or twice a year, a DST-sensitive schedule combined with a local-time cron daemon is one of the first things worth checking.

On modern Linux systems, systemd timers are increasingly used as an alternative to crontab for scheduling. A timer unit pairs with a regular systemd service unit and uses OnCalendar= expressions — a more readable syntax than cron's five fields, e.g. OnCalendar=Mon..Fri 09:00 — and gets systemd's other machinery for free: structured logging through journalctl, the ability to declare that a timer's job shouldn't start until another service is ready, and Persistent=true, which catches up a missed run (say, after the machine was off overnight) instead of just skipping it like traditional cron does.

Cron remains simpler to reason about for a single, self-contained scheduled command, and its five-field syntax is portable across virtually every Unix-like system without any systemd dependency — which is exactly why it's still the format most schedulers, CI systems and cloud cron services (including this tool) standardize on, even on systems that use systemd timers internally.

A cron job that errors out doesn't show a red X in your terminal — there's no terminal, since cron runs the command detached from any interactive shell. By default, whatever the job writes to standard output and standard error gets mailed to the crontab owner's local mail account, which on most modern servers goes nowhere useful because no mail transfer agent is configured to actually deliver it anywhere a human will see.

That's the single most common reason a cron job that's "been failing for weeks" goes unnoticed: the failure output exists, it's just being generated into a mail queue nobody reads. The fix is almost always explicit: redirect output to a log file (>> /var/log/job.log 2>&1), set MAILTO in the crontab to a real address if mail delivery is actually configured, or have the job itself push its result to a monitoring or alerting endpoint on completion or failure.