Linux Basic — cron vs at vs systemd
cron vs at vs systemd
Three main ways to schedule scripts on Linux. Each has a sweet spot.
Quick Comparison
| Tool | Best For | Portability | Complexity |
|---|---|---|---|
| cron | recurring tasks (daily, hourly) | universal | low |
| at | one-off delayed tasks | POSIX | trivial |
| systemd timers | complex deps, logging integration | Linux-only | medium |
cron
Recurring schedules. Runs as a daemon, reads /etc/crontab and user crontabs (crontab -e).
Pros:
- Universal (every Unix has it)
- Dead simple for “run daily at 2am”
- Per-user and system-wide options
Cons:
- Limited to time-based triggers (no “on boot” or “after network”)
- Minimal logging by default
- Awkward for complex dependencies
Use when: task runs on a fixed schedule and doesn’t need systemd integration.
at
Runs a command once at a specified time.
echo "backup.sh" | at 11pm
Pros:
- Zero config — just queue and forget
- POSIX-standard
Cons:
- Not for recurring tasks
- No built-in retry on failure
Use when: you need a one-off delayed execution (e.g., shutdown in 4 hours, reboot at midnight).
systemd Timers
Modern replacement for cron on systemd-based distros. Pairs a .timer unit with a .service unit.
Pros:
- Rich scheduling (OnBootSec, OnUnitActiveSec, OnCalendar with timezone)
- Integrates with systemd logging (
journalctl -u mybackup.service) - Dependency ordering (wait for network, run after another unit)
- Persistent timers survive reboots
Cons:
- Linux-only (no BSD, macOS)
- More boilerplate than cron
- Requires root or user units in
~/.config/systemd/user/
Use when: you need advanced scheduling, dependencies, or want logs in journalctl.
Decision Tree
- One-off task? → at
- Recurring, simple schedule, must work on BSD/macOS? → cron
- Recurring, needs systemd features (deps, logging, persistence)? → systemd timer
Next → Automation-Ready Scripts
