Systemd Timers vs Cron: Modern Task Scheduling di Linux Production

Selama bertahun-tahun, cron jadi andalan buat scheduling needs di server. Backup cron, monitoring cron, cleanup cron — semua cron. Tapi cron punya kelemahan fundamental: gak punya built-in logging yang proper, gak ada notification kalau gagal, dan gak ada mekanisme untuk cek apakah task udah jalan.

Sejak insiden itu, migrate ke systemd timers. Dan perbedaannya luar biasa. Artikel ini bakal compare keduanya dengan data real dari production deployment di 5 server yang manage.

Cron: Still Works, Tapi...

Cron udah ada sejak 1975 — lebih tua dari banyak programmer yang baca artikel ini. Dia reliable untuk use case dasar: schedule task di waktu tertentu. Tapi ada beberapa fundamental limitations yang makin terasa di production modern:

# /etc/crontab example
0 3 * * * root /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
*/5 * * * * www-data /usr/local/bin/health-check.sh
0 0 * * 0 root /usr/local/bin/cleanup.sh

Limitations cron yang gw alami di production:

• No logging standard: Cron cuma log ke syslog. Lo harus manually redirect output ke file sendiri. Dan kalau lo gak redirect, output-nya hilang. Pernah spend 2 jam debug cron job yang ternyata output-nya cuma ke /dev/null.
• No failure notification: Kalau cron job gagal, gak ada yang kasih tahu lo. Lo cuma tau kalau lo baca log manual — yang jarang dilakukan sampai ada masalah.
• No dependency management: Lo gak bisa bilang "jalankan task ini SETELAH service X ready." Cron cuma bisa schedule berdasarkan waktu, bukan state.
• No resource limits: Cron job bisa consume semua CPU/memory tanpa batas. Satu backup job yang runaway bisa bikin整个 server lambat.
• Timezone hell: Cron pake timezone server, bukan user. DST changes bisa bikin task jalan 2x atau 0x. Pernah kena DST bug yang bikin backup jalan 2 kali sehari selama seminggu.
• No concurrent run control: Kalau task sebelumnya belum selesai, cron bisa trigger lagi. Backup yang butuh 2 jam bisa overlap dengan backup berikutnya.

Systemd Timers: The Modern Alternative

Systemd timers adalah replacement modern untuk cron. Setiap timer punya service unit yang mendeskripsikan apa yang harus dilakukan, dan timer unit yang mendeskripsikan kapan harus dilakukan:

# /etc/systemd/system/backup.timer
[Unit]
Description=Daily Backup Timer

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

# /etc/systemd/system/backup.service
[Unit]
Description=Daily System Backup
After=network.target postgresql.service

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/backup.sh
StandardOutput=journal
StandardError=journal

# Resource limits (cron gak bisa ini!)
MemoryMax=512M
CPUQuota=50%

# Security hardening
ProtectSystem=strict
ProtectHome=true
NoNewPrivileges=true
PrivateTmp=true
ReadWritePaths=/var/backup

Yang langsung keliatan: systemd timer punya resource limits, security sandboxing, dan dependency management. Cron gak bisa ini. Dan semua output otomatis logged ke journal — gak perlu manual redirect.

Head-to-Head Comparison

Practical Example: Backup Job Comparison

Lo lihat perbedaannya side by side:

Cron version:

# /etc/crontab
0 3 * * * root /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Simple, tapi: kalau backup gagal? Lo cuma tau kalau lo baca log manual. Kalau server restart jam 2:59? Backup skip hari itu. Kalau backup jalan 5 jam dan mulai lagi jam 3? Overlap, bisa corrupt data.

Systemd version:

# backup.timer
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
RandomizedDelaySec=300

# backup.service
[Unit]
After=postgresql.service
Requires=postgresql.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

OnFailure=backup-notify.service

MemoryMax=1G
TimeoutStartSec=3600

StandardOutput=journal
StandardError=journal

# backup-notify.service
[Unit]
Description=Backup Failure Notification

[Service]
Type=oneshot
ExecStart=/usr/local/bin/notify-telegram.sh "BACKUP FAILED on $(hostname)"

Fitur kunci yang di-enable:

• Persistent=true: Kalau timer missed (server restart), task dijalankan saat boot berikutnya. Gak ada yang skip.
• OnFailure=: Kalau backup gagal, notifikasi otomatis dikirim ke Telegram. Gak perlu baca log.
• After=postgresql.service: Backup cuma mulai setelah Postgres ready. Gak ada race condition.
• MemoryMax=1G: Backup gak boleh consume lebih dari 1GB RAM. Kalau lebih, OOM kill — tapi gak impact server.
• TimeoutStartSec=3600: Max 1 jam. Kalau lebih lama, kemungkinan ada masalah.
• journalctl logging: Semua output otomatis logged dengan structured format. Queryable dengan filter.

Monotonic Scheduling: Timer Tanpa Wall Clock

Selain OnCalendar (wall clock), systemd timers support monotonic timestamps — scheduling berdasarkan waktu berlalu, bukan waktu absolut. Ini powerful untuk use case yang butuh interval tetap:

# Run 5 menit setelah boot, lalu setiap 30 menit
[Timer]
OnBootSec=5min
OnUnitActiveSec=30min

# Run 1 jam setelah service sebelumnya selesai
[Timer]
OnUnitInactiveSec=1h

Kenapa ini penting? Karena OnCalendar bisa "miss" kalau server restart di antara schedule. Tapi OnUnitActiveSec selalu trigger relatif terhadap waktu terakhir task jalan — jadi gak ada yang terlewat. Ini analogi yang sama dengan setInterval vs setTimeout di JavaScript.

Gw pake pola ini untuk monitoring check: setiap 30 menit, cek apakah service masih hidup. Kalau pakai OnCalendar, jam 3:00 bisa kelewat. Dengan OnUnitActiveSec=30min, interval tetap 30 menit regardless of schedule disruptions.

# Lihat semua timers dan status
systemctl list-timers --all

# Output:
# NEXT                         LEFT       LAST                         PASSED   UNIT
# Mon 2026-07-05 03:00:00      6h left    Sun 2026-07-04 03:00:00      18h ago  backup.timer
# Mon 2026-07-05 00:00:00      3h left    Sat 2026-07-04 00:00:00      21h ago  cleanup.timer

# Lihat log dari backup terakhir
journalctl -u backup.service --since "24 hours ago" --no-pager

# Cek apakah timer aktif
systemctl status backup.timer

# Lihat semua runs dalam sebulan
journalctl -u backup.service --since "1 month ago" | grep -E "Started|Failed|Completed"

# Lihat duration setiap run
journalctl -u backup.service --since "1 week ago" -o json |   python3 -c "import sys,json; [print(json.loads(l)['MESSAGE']) for l in sys.stdin if 'MESSAGE' in json.loads(l)]"

# monitoring.service — health check
[Unit]
Description=System Health Check

[Service]
Type=oneshot
ExecStart=/usr/local/bin/health-check.sh
SuccessExitStatus=0 1
# Exit code 1 = warning, bukan error

# monitoring-failure.service — critical failure handler
[Unit]
Description=Monitoring Failure Handler

[Service]
Type=oneshot
ExecStart=/usr/local/bin/critical-alert.sh "Health check failed!"