THE TWO CLOCKS

The same job — nightly backup at 03:30 — on both clocks, and what each one leaves behind:

30 3 * * * /usr/local/bin/backup.sh

# foo.timer
[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
# foo.service — the job itself

the schedule verdict: cron's five fields are the compact incumbent; OnCalendar is more verbose but strictly more expressive — Mon..Fri 09..17:00:00 is one line, and RandomizedDelaySec stops a thousand machines hammering one server

these clocks re-stamp from the record's own commands — they cannot read your machine's journal; where your journal actually is: sections 04 and 05.

THE PRACTICAL GAPS

• Logging: timers log stdout/stderr to the journal per unit; cron at best mails the local user.
• Missed runs: a timer with Persistent=true runs once on boot if its schedule was missed; cron just skips.
• Dependencies: timers can wait for network-online.target or mount points; cron needs you to hand-roll retry logic in the script.
• Syntax: cron is one line; a timer is two files. That is the entire cost of switching.
• Monotonic option: OnBootSec=15min — wall-clock changes cannot confuse it.

04TEST A TIMER WITHOUT WAITING

Three commands answer everything — list what is scheduled and when it next fires, run the job by hand exactly as the timer would, then read its logs:

systemctl list-timers --all                 # every timer, next + last run
sudo systemctl start backup.service         # fire the job now, same unit as the timer
journalctl -u backup.service -f             # watch its output live

Note the split: systemctl start backup.timer arms the schedule; the service is the job. If list-timers shows your timer, systemctl status backup.service is green, and the journal shows your output, the whole chain works.

verify: systemctl list-timers --all → your timer, last + next run listed

05RUN A CRON JOB MANUALLY

Cron jobs run with a stripped environment, which is why "works in my shell, fails in cron" is a genre of bug. To reproduce cron faithfully, run the command through sh with the environment cron would use:

crontab -l                                  # confirm the exact line
env -i SHELL=/bin/sh PATH=/usr/bin:/bin sh -c '/usr/local/bin/backup.sh'
grep CRON /var/log/syslog | tail            # did cron even fire it? (Debian/Ubuntu)
journalctl -u cron -n 20                    # same, on systemd distros

That env -i line is the honest manual test: a bare environment with cron's default PATH. The two cron classics — a bare PATH and an unquoted % (cron treats it as a newline) — both show up immediately in that test.

verify: journalctl -u cron -n 20 → your command's CRON entry

"MY TIMER ISN'T TRIGGERING"

A timer that looks dead is usually its service failing instantly. Four causes, in the order to check them:

1. Service and timer names do not match. foo.timer fires foo.service — a typo or a renamed unit means the timer "runs" into nothing. systemctl cat foo.timer shows exactly what it targets.
2. Edited but not reloaded. After changing a unit file: sudo systemctl daemon-reload && sudo systemctl restart foo.timer. Without this your new schedule is not live.
3. Wrong status command. systemctl status foo.timer always shows active even when idle — read list-timers instead.
4. The service it fires is failing instantly. journalctl -u foo.service --since -1h shows the crash that list-timers hides.

verify: journalctl -u foo.service --since -1h → the crash list-timers hides

THE DECISION TABLE

Rules of thumb: shipping a job on your own systemd machine → timer. Quick personal reminder or a box you did not build → cron. Anything with dependencies, retries, or a need to know whether it actually ran → timer, always. The classic pattern — a nightly rsync backup under a timer with Persistent=true — guarantees the backup happens even if the machine was asleep at the scheduled minute, which cron simply cannot offer.

end of the two clocks · nothing fetched · everything local