My number one reason for using systemd timers is just that I find it more readable than cron. Usually I want to run things daily, weekly or monthlyand systemd timers make that very easy.

Here is an example:

backup.timer

[Unit]
Description=Run backup database daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=10

[Install]
WantedBy=timers.target

backup.service

[Unit]
Description=Backup database

[Service]
Type=oneshot
ExecStart=/bin/bash /path/to/backupscript.sh

Another great feature is that the output of the script is logged to journald which is very convenient when you are troubleshooting why your backup failed last night.

If you already know cron and are too lazy to learn something new, then use cron with the knowledge that it’s a personal failure and not a real technical decision… Otherwise, use systemd timers.

I was literally just pondering this. I’ve got a local backup job that is a very simple rsync command which I originally setup as a cron job. I’ve got a cloud backup job I setup later with systemd timers. I went to add a new backup job and had to decide which to go with.

There is absolutely still a place for the cron jobs. If you are aware of it’s limitations it cannot get simpler than a new /etc/cron.d/ file with a single line. But the systemd timer path offers some nice functionality in exchange for a tad more complexity and less footguns. Whichever one you understand the best is probably the best answer.

The entirety of cron documentation is contained in the twenty lines of comments in the new config file created by cron -e

The only thing you need to know is cron -e command. There’s no learning curve, it’s more like - you are a cron expert in five minutes after learning that such a tool exists.

For me ive always used:

• cron if its simple and can take care of itself.
• systemd if its more complex and needs the OS to do a thing related.

Its not a hard set rule but its like 95% cron and some systemd on the side for me.