What Is a Cron Job?
A command scheduled to run at fixed times by the cron daemon. The five-field syntax has barely changed since 1987.
A cron job is a command scheduled to run automatically at fixed times or intervals by cron, the time-based job scheduler built into Unix-like operating systems. The name comes from chronos, the Greek word for time.
Each job is one line in a file called a crontab, consisting of a schedule expressed in five fields followed by the command to execute.
Where the syntax came from
Periodic execution arrived in Unix at Bell Labs in the mid-1970s. The version shipped with Version 7 Unix in 1979, written by Brian Kernighan, ran as a daemon that woke once a minute, read a single crontab, and executed anything due as the superuser.
Paul Vixie released his implementation in May 1987, adding per-user crontabs, environment variables, step values, ranges, named months and weekdays, and the @reboot shortcut. Vixie cron became the default on most Linux and BSD systems and later became ISC Cron.
POSIX standardised the crontab format in 1992, mandating the five-field structure but not the conveniences Vixie added. That is why step values such as */5 are almost universally supported and still technically non-standard.
The five fields
| Position | Field | Allowed values | Note |
|---|---|---|---|
| 1 | Minute | 0-59 | |
| 2 | Hour | 0-23 | 24-hour clock, server local time |
| 3 | Day of month | 1-31 | |
| 4 | Month | 1-12 or JAN-DEC | Names are a Vixie extension |
| 5 | Day of week | 0-6 or SUN-SAT | 0 is Sunday; Vixie also accepts 7 |
An asterisk means every value. So 30 2 1 runs at 02:30 every Monday, and /15 * runs every fifteen minutes. Shortcuts including @daily, @hourly and @reboot cover the common cases.
Four traps that cause most cron failures
The first is the environment. Cron runs jobs with a minimal environment that is not your login shell's, so a command that works when you type it fails under cron because PATH is shorter. Using absolute paths for both the interpreter and the script avoids it.
The second is output. Cron mails standard output and standard error to the job's owner, and on most modern servers no mail transfer agent is configured. The output is generated, delivery fails, and the error message ceases to exist. This is the single biggest reason cron failures go unnoticed.
The third is time zones. Cron uses the server's local time, which means a schedule can shift by an hour twice a year under daylight saving, and a job scheduled during a skipped hour may not run at all.
The fourth is the day-of-month and day-of-week interaction. When both fields are restricted they are combined with OR, not AND. So 0 0 13 * 5 runs on the 13th of every month and also on every Friday, which is not Friday the 13th.
Cron expressions outside cron
The syntax long outlived the daemon. Kubernetes CronJob resources, GitHub Actions schedule triggers, AWS EventBridge Scheduler and Spring's @Scheduled annotation all accept cron expressions.
Their guarantees differ, and it is worth reading the fine print. Scheduled workflows on shared CI platforms in particular are queued rather than guaranteed, and can be delayed or skipped under load, which is a different reliability model from a daemon on your own server.
Why scheduled jobs go unmonitored
A cron job that stops running produces no error, no failed request and no log entry, because the thing that did not happen cannot log. If the job's output was going to mail that nobody receives, even a loud failure is silent in practice.
Detecting this requires inverting the question and alerting on the absence of a completion signal rather than the presence of an error.
Related concepts
That inversion is covered in heartbeat and cron monitoring, the underlying pattern in what is a dead man's switch, and the alert timing in what is a grace period.