Cron Job Wiki: The Complete Reference for Cron & Crontab

What Is a Cron Job? (Quick Definition)

A cron job is a scheduled task that runs automatically at a fixed time or interval, executed by a background process on Unix-like systems called the cron daemon. The term is often confused with two related ones: cron, the daemon and scheduling system as a whole, and crontab, the configuration file (short for "cron table") where scheduled jobs are listed. Boiled down: cron is the system, crontab is the file you edit, and a cron job is one scheduled entry inside it.

This distinction trips up a lot of developers scanning man pages or old forum threads at 2am trying to figure out why a job didn't run. That's the gap this page closes — a single cron job reference you can bookmark or send to a teammate instead of stitching together Wikipedia, man pages, and Stack Overflow answers.

A Brief History of Cron

Cron's origins trace back to Version 7 Unix in the late 1970s, where it was introduced as a simple time-based job scheduler. Most modern systems descend from Vixie cron, a 1987 rewrite by Paul Vixie that added user-level crontabs, better field syntax, and the flexibility still found in Linux cron implementations today. Vixie's version became the de facto standard so thoroughly that "cron" and "Vixie cron" are often used interchangeably.

Cron's behavior was formalized in 1992 when POSIX standardized the five-field time syntax, giving vendors a shared baseline so scripts could move between systems predictably. That standardization is also why syntax still varies slightly today — POSIX cron defines the core fields, but individual implementations (Vixie cron, BSD cron, various Linux distributions) layer on extensions like special strings or environment handling differently. For a deeper walkthrough, the Bumble Tech history of cron is a solid technical read.

Key Terminology Glossary

Quick, scannable definitions for the terms that get tangled together most often:

• Cron daemon — The background process (crond on most Linux systems) that wakes up every minute, checks crontabs, and executes any job whose schedule matches the current time.
• Crontab — The file format and command (crontab -e) used to define scheduled jobs, either per-user or system-wide.
• Cron expression — The five-field time pattern (minute, hour, day of month, month, day of week) that tells cron when to run a job.
• Cron job — A single scheduled command or script defined by one line in a crontab.
• MAILTO — A crontab variable that tells cron where to email job output; misconfigured MAILTO is a common reason teams believe they're getting failure alerts when they aren't. See Cron Job MAILTO: Correct Syntax and Why It Fails for the exact syntax.
• Exit code — The number a script returns on completion; 0 means success, anything else typically signals failure, but cron itself doesn't interpret or alert on this value.
• Silent failure — A job that fails, hangs, or simply stops running without producing any visible error, log entry, or notification.

Crontab Syntax at a Glance

Every standard crontab line follows the same five-field structure, followed by the command to run:

* * * * * command-to-run
│ │ │ │ │
│ │ │ │ └── day of week (0–6)
│ │ │ └──── month (1–12)
│ │ └────── day of month (1–31)
│ └──────── hour (0–23)
└────────── minute (0–59)

For common schedules, cron implementations support special strings as shorthand — documented precisely in the crontab(5) man page:

Special String	Equivalent To	Runs
@reboot	—	Once, at system startup
@yearly / @annually	0 0 1 1 *	Once a year
@monthly	0 0 1 * *	Once a month
@weekly	0 0 * * 0	Once a week
@daily / @midnight	0 0 * * *	Once a day
@hourly	0 * * * *	Once an hour

If you're writing your first crontab entry rather than just looking one up, How to Create a Cron Job: A Fast 5-Step Tutorial walks through it step by step. Tools like crontab.guru are also useful for validating expressions interactively once you understand the field structure.

Common Cron Terms You'll See Elsewhere

A few adjacent concepts show up constantly in cron discussions and are worth defining:

• cron.d — A directory (/etc/cron.d/) where system packages and admins can drop additional crontab files without editing a user's personal crontab, useful for job files managed by configuration tools or package installers.
• anacron — A companion utility designed for machines that aren't always on, like laptops or desktops. Unlike cron, which assumes the system is running continuously, anacron catches up on missed jobs the next time the machine boots.
• cron-job.org — A hosted, browser-based scheduler that lets users trigger HTTP requests on a schedule without running their own server. It solves a similar problem to self-hosted cron but with a web console; see Cron Job Org Console: What It Means & Why Teams Outgrow It for where teams typically hit its limits.
• systemd timers — A modern alternative to cron built into systemd-based Linux distributions. The comparison usually comes down to dependency management and logging: timers integrate with systemd unit dependencies and journal logging, while cron stays simpler and more portable across Unix-like systems.

The One Thing the Cron Wiki Won't Tell You: Cron Doesn't Alert You

Here's the part most cron documentation glosses over: cron has no built-in concept of success or failure. It runs the command at the scheduled time, and that's the extent of its job. If the script exits with an error, hangs indefinitely, or the server it lives on goes down entirely, cron doesn't retry, doesn't page anyone, and doesn't flag anything as broken — the job simply fails silently until someone notices missing data, a broken report, or an angry customer.

MAILTO can forward output to an inbox, but that only works if the job runs at all and if someone's actually reading cron emails — which, in most teams, nobody is. This is the core reason cron job monitoring exists as its own category: something has to sit outside the cron daemon and independently verify that jobs checked in when expected. If you want to know exactly how to check whether a job actually ran and succeeded before wiring up alerts, Check Cron Job Status: Did It Actually Run and Succeed? covers the practical steps.

This is where Cronevra fits in: it monitors your scheduled HTTP jobs from the outside, tracks execution history, and sends cron job alerts the moment a run is late, missing, or fails — no cron internals to configure. If that sounds like the missing piece for your setup, the pricing page is a low-friction place to see whether it fits your stack.

Frequently Asked Questions

What exactly is a cron job vs a crontab vs the cron daemon?

A cron job is a single scheduled task; a crontab is the file listing one or more cron jobs; the cron daemon is the background process that reads crontabs and executes jobs at the right time. Think of cron as the system, crontab as the file, and cron job as an individual entry in it.

Where did cron come from and why does syntax vary slightly between systems?

Cron originated in Version 7 Unix in the late 1970s and was substantially rewritten by Paul Vixie in 1987 into what's now called Vixie cron, the basis for most modern implementations. POSIX standardized the core five-field syntax in 1992, but individual systems still add their own extensions, like special strings, which is why syntax isn't perfectly identical everywhere.

What do the @daily, @hourly, @reboot special strings mean?

They're shorthand for common schedules: @hourly runs once an hour, @daily runs once a day at midnight, and @reboot runs once at system startup rather than on a recurring schedule. They're defined precisely in the crontab(5) man page and supported by most modern cron implementations.

What's the difference between cron and anacron, or cron and systemd timers?

Anacron is built for machines that aren't always running and catches up on missed jobs after boot, while cron assumes continuous uptime and simply skips runs it misses. Systemd timers are a newer alternative built into systemd-based Linux distributions, offering tighter integration with system logging and service dependencies than traditional cron.

Why doesn't cron tell you when a job fails?

Cron only executes commands at scheduled times; it has no built-in mechanism to check exit codes, detect hangs, or notify anyone on failure. That's why jobs can fail silently for days unless external monitoring is layered on top to verify each run actually completed successfully.