Cron Daemon

The cron daemon (crond or cron) is a long-running background process on Unix-like systems that executes commands on a schedule. It reads a table of scheduled tasks (the crontab) and runs each task when its cron expression matches the current time.

How the cron daemon works

The daemon wakes up every minute, reads all crontab files, checks which entries match the current minute, and spawns a shell process for each match. Once the command finishes, the daemon captures its output and (on traditional systems) mails it to the crontab owner.

1. Startup — the cron daemon starts at boot and runs continuously in the background
2. Every minute — it checks all crontab entries against the current timestamp
3. Match found — it forks a shell process and runs the command
4. Output capture — stdout and stderr are collected and (optionally) mailed to the user

Crontab: the schedule file

The crontab (cron table) is a per-user file that lists scheduled commands. Each line has a cron expression followed by the command to run:

Common crontab commands:

Command	Description
crontab -e	Edit your crontab
crontab -l	List your crontab entries
crontab -r	Remove your entire crontab

System-level vs user-level cron

User crontabs live in /var/spool/cron/ and run as the owning user. System crontabs (/etc/crontab and files in /etc/cron.d/) have an additional field for the user to run the command as. System crontabs are typically managed by root and are used for OS-level maintenance tasks.

Limitations of the cron daemon

• No retry logic — if a job fails, cron doesn't retry it. The next execution happens at the next scheduled time.
• No execution history — cron doesn't log success/failure, response times, or output in a structured way. You get syslog entries at best.
• No alerting — cron doesn't notify you when a job fails. You'd need to build that into each script.
• Server-dependent — if the server reboots, missed schedules are skipped (except on systems with anacron).
• No concurrency control — cron will happily start a second instance of a job while the first is still running, leading to concurrency issues.
• Timezone confusion — system cron uses the server's timezone, which can cause issues with daylight saving changes.

Cron alternatives

For production workloads that need retries, monitoring, or cross-service scheduling, teams typically outgrow the cron daemon and move to:

• Framework schedulers — Laravel's task scheduler, Celery Beat, node-cron
• Cloud schedulers — AWS EventBridge, Google Cloud Scheduler
• External HTTP schedulers — services like Recuro that call your endpoints on a schedule with built-in retries, logging, and alerts

FAQ

What is the cron daemon?

The cron daemon is a background process on Linux and macOS that runs scheduled commands. It checks its schedule file (crontab) every minute and executes any commands whose time has come.

How do I check if cron is running?

Run systemctl status cron (systemd) or service cron status (SysV). On macOS, check with launchctl list | grep cron.

Why didn't my cron job run?

Common causes: the cron daemon isn't running, the cron expression is wrong, the command's PATH isn't set correctly in the crontab environment, or the script has a permissions issue. Check /var/log/syslog or /var/log/cron for clues.

The cron daemon uses cron expressions to define schedules and crontab files to store them. For background jobs that need retries and monitoring, consider pairing cron with a job queue or replacing it with an external scheduler that handles exponential backoff, heartbeat monitoring, and health checks natively.