Cron
Classic Unix job scheduler
Systemd Timer
Modern service-based scheduler
Comprehensive comparison between Cron and Systemd Timer schedulers. Learn when to use each, their features, pros and cons, and how to migrate between them.
Quick Comparison
| Feature | ⏰ Cron | ⚙️ Systemd Timer |
|---|---|---|
| Scheduling Style | Time-based only | Time or event-based |
| Granularity | Minutes | Microseconds |
| Dependencies | None | Full support |
| Logging | Basic email/log | journald integration |
| Per-user jobs | Yes | Yes |
| Monotonic timers | No | Yes |
| Resource tracking | No | Yes (cgroups) |
| Platform coverage | Universal | systemd only |
| Learning curve | Simple | Moderate |
| Container friendly | Excellent | Poor |
Core Features
Scheduling Precision
Cron: Minute-level
Systemd Timer: Microsecond-level
💡 Why: Systemd timers support much finer-grained scheduling with microsecond precision, while cron only supports minute-level granularity.
Real-time Scheduling
Cron: ✅ Full Support
Systemd Timer: ✅ Full Support
💡 Why: Both support traditional time-based scheduling (e.g., "every day at 3 AM").
Monotonic Timers
Cron: ❌ Not Supported
Systemd Timer: ✅ Full Support
💡 Why: Systemd supports timers based on time elapsed since boot or other events, which cron cannot do.
Event Triggers
Cron: ❌ None
Systemd Timer: ✅ Multiple Events
💡 Why: Systemd can trigger on hardware events, path changes, and other system events.
Configuration & Management
Configuration Format
Cron: Crontab (simple)
Systemd Timer: INI-style units
💡 Why: Cron uses a simple, well-known crontab format. Systemd uses more complex unit files.
Per-User Scheduling
Cron: ✅ Supported
Systemd Timer: ✅ Supported
💡 Why: Both support per-user scheduling (user crontabs vs systemd user units).
Environment Variables
Cron: Limited
Systemd Timer: Full Support
💡 Why:
Dependency Management
Cron: ❌ None
Systemd Timer: ✅ Full Support
💡 Why: Systemd timers can depend on services, sockets, targets, and other units.
Logging & Monitoring
Built-in Logging
Cron: Email/logs
Systemd Timer: journald
💡 Why: Systemd integrates tightly with journald for structured, searchable logs.
Job History
Cron: Limited
Systemd Timer: ✅ Tracked
💡 Why: Systemd keeps detailed history of timer triggers and service results.
Resource Monitoring
Cron: ❌ None
Systemd Timer: ✅ cgroups
💡 Why: Systemd tracks resource usage via cgroups for each service.
Failure Handling
Cron: Email only
Systemd Timer: Multiple options
💡 Why: Systemd supports on-failure triggers, restart policies, and dependency-based reactions.
Performance & Resources
Memory Usage
Cron: ~1-2 MB
Systemd Timer: ~5-10 MB
💡 Why: Cron daemon uses minimal memory. Systemd is already running, so timers add negligible overhead.
Startup Time
Cron: Fast
Systemd Timer: Instant
💡 Why: Systemd is part of init, already running at boot.
Scalability
Cron: Good
Systemd Timer: Excellent
💡 Why: Systemd handles thousands of units more efficiently with modern process management.
System Integration
Cron: Standalone
Systemd Timer: Integrated
💡 Why: Systemd timers are native to systemd-based systems.
Platform & Compatibility
Linux Support
Cron: ✅ Universal
Systemd Timer: systemd only
💡 Why: Cron works on all Linux systems. Systemd timers only work on systemd-based distributions.
Unix/BSD Support
Cron: ✅ Yes
Systemd Timer: ❌ No
💡 Why: Cron is available on virtually all Unix-like systems.
macOS Support
Cron: ✅ launchd/cron
Systemd Timer: ❌ No
💡 Why: macOS uses launchd (not systemd), but cron is available.
Container Support
Cron: ✅ Easy
Systemd Timer: Complex
💡 Why: Cron works in minimal containers. Systemd requires full systemd init.
Practical Examples
Simple Daily Backup
Cron
# Run backup at 2 AM daily
0 2 * * * /root/backup.sh
Cron is simpler for this basic task. Systemd requires two files (timer + service) but offers persistence across reboots.
Run 15 Minutes After Boot
Cron
# Not easily supported
# Would need @reboot with sleep
Systemd natively supports boot-delayed execution. Cron would need complex workarounds.
Run When Network is Up
Cron
# Not supported
Systemd can wait for specific system states. Cron has no dependency awareness.
Migration Guide
Cron → Systemd Timer
- → Create both .timer and .service files (cron entry = timer + service combined)
- → Use OnCalendar for time-based schedules (converts cron expressions)
- → Use Persistent=true to run jobs that were missed during downtime
- → Move environment variables from crontab to [Service] Environment=
- → Replace mail output with journald logging
- → Convert user crontabs to systemd user units (~/.config/systemd/user/)
- → Use systemctl list-timers to view all timers (similar to crontab -l)
Cron → Systemd Timer
- → Lose dependency management - script must handle dependencies
- → Convert OnCalendar to cron expressions (minute hour day month dow)
- → Replace monotonic timers (OnBootSec) with @reboot and sleep
- → Remove event-based triggers (cron is time-only)
- → Environment goes in crontab or script
- → Logging must be handled manually (syslog, custom files)
- → No built-in persistence - track last run manually in scripts
Frequently Asked Questions
Which should I choose for a new Linux server? ▼
Can cron and systemd timers coexist? ▼
How do I view all scheduled tasks like crontab -l? ▼
Do systemd timers work in Docker containers? ▼
Is cron being deprecated? ▼
Can systemd timers send emails on failure like cron? ▼
Which uses fewer system resources? ▼
How do I schedule a job to run every 10 seconds? ▼
Verdict: Neither - Choose based on requirements
Both cron and systemd timers are powerful job schedulers serving different needs. **Cron remains the universal choice** for simple, portable scheduling across all Unix-like systems. **Systemd timers excel** on modern Linux distributions requiring complex dependencies, event triggers, and integrated logging.
Recommendation
Use **cron** for simple periodic tasks, cross-platform compatibility, legacy systems, and containers. Use **systemd timers** for modern Linux servers, service orchestration, event-driven scheduling, and when you need tight integration with system services.