What Is a Cron Job? Scheduled Tasks on Servers Explained
A cron job is a scheduled task on Unix-like operating systems (Linux, macOS, BSD) that runs a command or script automatically at specified times — every minute, hourly, daily at 2 a.m., weekly on Sundays, or on custom intervals. The cron daemon reads schedule definitions and launches jobs without manual intervention, powering backups, log rotation, email digests, and database maintenance across millions of servers.
What It Is
Think of cron as a reliable alarm clock for server commands. You set the time and frequency once; the system executes the task repeatedly until you change or remove the schedule.
Core terms:
| Term | Meaning |
|------|---------|
| cron | Background daemon that triggers scheduled jobs |
| crontab | Table file listing a user's cron jobs |
| cron job / cron entry | One scheduled line with timing + command |
| crontab -e | Edit your user's schedule interactively |
Each crontab line has five time fields (minute, hour, day of month, month, day of week) plus the command:
`
0 2 * * * /usr/local/bin/backup.sh
`
This runs backup.sh at 02:00 every day.
Special strings exist: @daily, @hourly, @reboot (run at startup).
Windows uses Task Scheduler instead; cloud platforms offer EventBridge, Cloud Scheduler, or hosted cron in PaaS dashboards — the concept translates even when the name differs.
Why It Matters
Automated backups — snapshot databases and upload to object storage on a fixed schedule so recovery points exist if ransomware or operator error strikes.
Log and cache cleanup — prevent disks filling from unbounded log growth or temp files.
Reporting — generate nightly sales CSVs, analytics rollups, or invoice batches.
Certificate and subscription renewals — Certbot often runs via cron to renew TLS certificates before expiry.
Health checks — ping services and alert if endpoints fail outside business hours.
Cost control — scale down dev environments nights and weekends on a schedule.
Without scheduling, teams rely on humans remembering repetitive tasks — error-prone at 3 a.m.
How It Works
1. cron daemon (crond) starts at boot and runs continuously.
2. It reads system crontab (/etc/crontab, /etc/cron.d/*) and per-user crontabs (/var/spool/cron/crontabs/ or similar).
3. Every minute, cron evaluates which entries match the current time.
4. Matching jobs execute as the specified user, with environment variables often minimal — scripts should set paths explicitly.
5. Output (stdout/stderr) may email the user via MAILTO= or redirect to log files in the command line.
Cron syntax example
`
*/15 * * * * curl -fsS https://healthcheck.example/ping
0 0 1 * * /scripts/monthly-report.sh
30 9 * * 1-5 /scripts/weekday-reminder.sh
`
* means every value; */15 every 15 units; 1-5 Monday–Friday.
Pitfalls
- Timezone — cron uses server local time unless configured otherwise; UTC is common on cloud VMs.
- Overlapping runs — long jobs started every minute can stack; use flock or check-if-running guards.
- Missing PATH — cron environments differ from interactive shells; use full paths or set PATH in crontab.
- Silent failures — redirect output to logs and monitor them.
Alternatives
systemd timers on modern Linux offer dependency awareness and logging integration. Kubernetes CronJob, GitHub Actions scheduled workflows, and serverless schedulers replace traditional cron in cloud-native stacks.
Common Examples
| Job | Typical schedule |
|-----|------------------|
| Database dump | Daily 3:00 a.m. |
| Rotate Apache logs | Weekly |
| Sync files to S3 | Every 6 hours |
| Clear temp uploads | Hourly |
| Renew Let's Encrypt | Twice daily (Certbot default suggestion) |
Shared hosting control panels (cPanel) expose cron UI for non-CLI users running PHP or wget URLs.
Common Misconceptions
"Cron jobs run exactly on the second"
Cron has one-minute resolution. Sub-minute scheduling needs other tools.
"Cron guarantees a job finishes before the next run"
No — if a job exceeds its interval, runs overlap unless prevented.
"Windows servers use cron natively"
Windows uses Task Scheduler; cron is Unix-family terminology, though WSL can run cron inside Linux subsystem.
"Web cron URLs are as secure as server cron"
Hitting https://yoursite.com/cron.php?key=secret from external schedulers exposes URL secrets in logs and depends on HTTP — acceptable for some hosts, weaker than local execution.
"Deleting a script removes the cron job"
The crontab entry remains until edited — causing error emails or failed runs.
FAQ
How do I list my cron jobs?
Run crontab -l for your user. System jobs appear in /etc/cron.d/ and related directories (requires root to view).
Can cron run as root?
Yes — root's crontab or /etc/cron.d/ entries run with full privileges — use sparingly and validate scripts.
What is @reboot?
A special cron keyword running a command once when the system starts — useful for services not managed by systemd.
Why did my cron job work manually but not from cron?
Usually PATH, permissions, or environment variables. Log output to a file to debug.
Are cron jobs deprecated?
On desktops, systemd timers compete on Linux. Cron remains widely deployed and understood; many clouds still expose "cron job" UIs.
When Cron Jobs Matter Most
Cron shines for predictable repetition — nightly database dumps, weekly log rotation, hourly cache warming, and certificate renewal checks. It is the wrong tool for complex dependency chains better handled by workflow engines (Airflow, Temporal) or event-driven serverless triggers. Production cron demands logged output, alerting on failure, and idempotent scripts that survive partial runs without corrupting data.
The Takeaway
A cron job is an automated scheduled command on Unix-like systems, defined in crontab files with minute-hour-date patterns. It underpins server maintenance, backups, and batch processing — but needs correct paths, timezone awareness, overlap guards, and log monitoring to run reliably.
*This article is for general informational purposes only and does not constitute professional system administration advice.*