Cron Job Unix: How It Works and Why It Fails Silently

What Is a Cron Job on Unix?

A cron job on Unix is a task scheduled to run automatically at a fixed time or interval, without a human launching it. The mechanism behind it is the unix cron daemon — a background process, traditionally named cron or crond, that wakes up periodically, checks configuration files called crontabs, and executes any command whose schedule matches the current time.

Cron exists because operating systems need a reliable way to run recurring maintenance and application work — log rotation, backups, report generation, cache warming, billing runs — without an operator manually triggering each one. The daemon itself is deliberately minimal: it doesn't know or care what your command does, only when to run it. That simplicity is why cron has survived, largely unchanged in concept, for close to five decades.

Where Unix Cron Came From

Cron's lineage traces back to Version 7 Unix in the late 1970s, developed at Bell Labs in the era of Ken Thompson and Brian Kernighan's foundational Unix work. The original daemon was single-user-oriented; Cron and Anacron (Binary Dodo) covers how that early implementation worked and how Unix System V later introduced per-user crontabs, letting multiple accounts on one machine each schedule jobs independently.

The next major inflection point was Paul Vixie's rewrite in the late 1980s, widely known as Vixie cron, which added richer scheduling syntax and became the de facto standard shipped across BSD and early Linux systems. Vixie cron's design decisions — including its silence-by-default behavior — still shape how cron behaves today. Modern systems mostly run descendants of that lineage: ISC cron (the maintained successor to Vixie's code) and community forks like cronie, favored by Red Hat–based and Debian-based distributions, alongside lighter alternatives like dcron and fcron built for embedded or resource-constrained environments. Cron in Linux: history, use and structure (Bumble Tech) walks through this fork history in more depth.

How the Cron Daemon Actually Works

The crond process runs continuously in the background from system boot. On most implementations it wakes once a minute, reads the relevant crontab files, and compares each entry's schedule fields against the current minute, hour, day, month, and weekday. Any match gets forked off as a new process, typically run under /bin/sh with a minimal, stripped-down environment — no shell profile, no interactive PATH, none of the environment variables your login shell quietly provides.

There isn't one crontab file — there are several. Each user has a personal crontab, editable via crontab -e and stored separately from other users' files. There's also a system crontab (often /etc/crontab) and drop-in directories like /etc/cron.d/ for package-installed jobs. Output handling is equally understated: by default, any stdout or stderr a job produces gets mailed to the owning user via the local mail system, and job invocations are logged to syslog — not to a dashboard, not to a file you're likely watching. That architecture is unremarkable until something breaks, which is where most teams' real problems start.

A Minimal Unix Crontab Example

A crontab line has five time fields followed by the command to run. A few examples:

0 3 * * * /usr/local/bin/backup.sh

Runs backup.sh every day at 3:00 AM.

*/15 * * * * curl -fsS https://example.com/health >> /var/log/health.log

Runs every 15 minutes, hitting an HTTP endpoint and logging the response.

30 9 * * 1 /usr/bin/php /var/www/app/artisan reports:weekly

Runs at 9:30 AM every Monday, generating a weekly report.

That's enough to get a basic unix cron job example running, but field-by-field syntax — ranges, steps, named months, special strings like @reboot — deserves more space than this article gives it. For the full breakdown, see Weekly Cron Job Syntax: Every Platform, Every Edge Case. For a purely conceptual definition of what a cron job actually is, Cron Jobs Meaning: A Clear Definition for Developers is a good companion read.

Not All Unix Cron Is the Same

Cron isn't one piece of software, it's a category. Debian and Ubuntu ship cronie or Vixie-derived cron depending on version — the Debian Wiki cron page documents exactly how Debian's package relates to Vixie cron and ISC cron upstream. Red Hat, Fedora, and CentOS also run cronie. macOS historically shipped Vixie cron but now leans on launchd for most system scheduling, with cron kept around mostly for compatibility. Alpine Linux and other minimal distros often use dcron for its small footprint, while fcron adds features like catching up on missed jobs after downtime — useful on machines that aren't always powered on.

The practical upshot: environment variable handling, logging destinations, permission models (like /etc/cron.allow and /etc/cron.deny), and support for extras like @reboot all vary between cronie vs Vixie cron vs fcron. If a job behaves differently on your laptop than on a production server, checking which cron variant is actually installed is a legitimate first debugging step.

Why Unix Cron Jobs Fail Silently

This is the core operational problem with cron, and it's a design choice, not a bug. The daemon logs invocation events to syslog and, if configured, mails command output — but it has no concept of success or failure beyond exit codes it never surfaces anywhere visible. A script that exits non-zero, hangs indefinitely, or dies from a missing environment variable produces no alert, nothing pushed to you. The job simply doesn't run, or runs badly, and cron moves on to the next minute as if nothing happened.

This explains the classic complaint: "it worked when I ran it manually, but not in cron." Manual execution inherits your full login shell environment — PATH, aliases, sourced profile scripts. Cron's execution environment is deliberately bare, so scripts relying on assumptions from an interactive shell fail differently, or fail silently, under cron.

Monitoring Unix Cron Jobs With Cronevra

Native Unix cron was built in an era when a sysadmin manually read logs and checked mail spools — it was never designed to proactively tell anyone when something went wrong. That gap is exactly what Cronevra closes. You point your existing cron job at a Cronevra endpoint — either by wrapping the command so it pings on success, or by having an HTTP-triggered job report directly — and Cronevra tracks execution history, detects missed or failed runs, and sends recovery alerts the moment a job that should have run doesn't. There's no daemon to replace and no syntax to relearn; it layers monitoring on top of the cron you already have. Check Cronevra's pricing to see which plan fits your job count, or start wrapping your first job today.

Frequently Asked Questions

Is cron only available on Unix systems?

Cron originated on Unix and remains most closely associated with Unix and Unix-like systems, including Linux distributions and BSD variants. Windows has its own separate scheduler, Task Scheduler, which isn't cron-compatible, though cron-like tools exist for Windows as third-party additions.

What's the difference between cron and crontab?

Cron is the daemon — the background process that wakes up and executes scheduled jobs. Crontab is the configuration file format and the command (crontab -e) used to create, view, or edit the schedule that cron reads.

Why does my cron job work when I run it manually but not on schedule?

Manual execution runs inside your full login shell, inheriting PATH, aliases, and environment variables from your profile scripts. Cron runs jobs with a minimal environment, so scripts that assume an interactive shell's context often fail or behave differently under cron.

Does Unix cron send an email if a job fails?

Only if mail is configured on the system and the job produces output on stdout or stderr — cron mails that output to the owning user by default. It doesn't detect "failure" as a concept; it only forwards whatever the command printed, and many servers don't even have a working local mail setup.

What's the difference between Vixie cron and cronie?

Vixie cron was Paul Vixie's late-1980s rewrite that became the standard for BSD and early Linux cron implementations. Cronie is a later community fork of Vixie cron, adopted by Red Hat– and Debian-based distributions, with added features like PAM support and SELinux integration.

How do I know if my Unix cron job actually ran?

By default, you'd need to check syslog or mail output manually — cron gives no proactive confirmation. Tools like Cronevra solve this by tracking each execution via an HTTP ping, so you get a recorded history and an alert if an expected run doesn't check in.