What Is a Cron Job (and Why Do They Fail Silently)?

Quick answer
A cron job is a command your server runs automatically on a schedule, defined in a crontab file.
Cron sends output to an email inbox nobody reads, which is why failures go unnoticed.
The fix is alerting: every scheduled job should notify you when it fails or stops running.

How do cron jobs work?

The cron daemon reads crontab files and runs the listed commands at the listed times. A crontab line has five time fields (minute, hour, day of month, month, day of week) followed by the command. The example below runs a backup script at 2:30 a.m. daily. Any output the command produces is emailed to the crontab owner by default.

# Run /home/me/backup.sh at 02:30 every day
30 2 * * * /home/me/backup.sh

# List your cron jobs
crontab -l

# Edit them
crontab -e

Why do cron jobs fail without anyone noticing?

Three reasons stack up. First, the default output destination is email, which most servers never deliver or read. Second, the environment a cron job runs in is minimal — no PATH, no shell profile — so scripts that work in your terminal fail under cron with cryptic errors like ‘command not found’. Third, a job that runs and exits 0 without doing its work (for example, a backup that writes an empty file) looks healthy. Silent success is the most common failure mode of all.

What’s the difference between cron and a scheduler service?

Cron runs locally on one machine. Managed schedulers — GitHub Actions scheduled workflows, AWS EventBridge, cron jobs on Fly.io or Railway, or a service like cron-job.org — run your task in the cloud and, crucially, give you a dashboard and notifications. For anything that matters, use a service that alerts on failure rather than bare cron.

Where this bites vibecoders
AI assistants love suggesting cron jobs for backups, scraping, or cleanups, and they rarely mention that the job will fail the first night and nobody will know. A vibecoder’s first cron job is often a database backup that silently stops after a disk fills up. The habit that saves you: every scheduled task must either notify you on failure or be monitored externally — never assume it ran.

Where AI coding assistants get this wrong

Writing crontab entries with no logging, so there’s nothing to inspect after a failure.
Using relative paths or shell aliases that don’t exist in cron’s minimal environment.
Assuming cron output is monitored when nothing reads the server mail.
Scheduling heavy jobs during peak hours because the assistant picked a time without thinking.

Checklist

Give every cron job an absolute path and full PATH in the script.
Redirect output to a log file: command >> /var/log/job.log 2>&1.
Use a managed scheduler or an uptime/alert service for anything that matters.
Test the job manually with the same environment cron uses.

FAQ

How do I make a cron job tell me when it fails?

Redirect output to a log, and add an explicit failure signal: exit non-zero on error, then wire that to an alert. Easier still, use a managed scheduler or a cron monitor such as healthchecks.io that alerts when a job misses its heartbeat.

Why does my script work in the terminal but fail in cron?

Cron runs with a nearly empty environment: no PATH, no HOME in some cases, no aliases. Use absolute paths for commands and scripts, and set PATH at the top of the script, or the shell can’t find executables like python3 or pg_dump.