SynologyRS
Administration

Automating routine work with cron and timers

📅 2025-01-20✎ 6 min read

Cron quirks, systemd timers, and logging jobs so you can prove they ran.

Automation is easy; proving it ran is the hard part. A cron job that silently fails for three months is not automation, it is a time bomb with a schedule. Here is how I make routine work both invisible and verifiable.

cron is fine, know its quirks

PATH=/usr/local/bin:/usr/bin:/bin
31 3 * * * /usr/local/bin/backup.sh >> /var/log/cron.log 2>&1

The two things that bite are the minimal environment and the fact that cron does not care whether your command worked. Always set PATH explicitly and redirect output somewhere you will read.

systemd timers for the important stuff

When a job matters, a systemd timer gives you status, logs, and retry for free. cron gives you nothing but the line itself.

[Unit]
Description=hourly health check
[Timer]
OnCalendar=hourly
Persistent=true
[Service]
Type=oneshot
ExecStart=/usr/local/bin/health-check.sh

Log so you can prove it

echo "$(date -Is) backup exit=$? bytes=$(du -sh /backups | cut -f1)" >> /var/log/backup.log

Every scheduled job appends a timestamped line. Six months from now you will be glad you can show that the backup ran at 03:11 and did not error, instead of hoping.

If a scheduled job does not log its result, it is not running — it is hoping.