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.

Automatic failure handling, advanced logging, independent execution environment control, cgroups support, service dependency management…

On the negative side, it takes slightly more work to configure timed tasks and there’s no integrated email support.

Refer to the Arch Wiki for more detailed information.

Also a cron guy, but systemd timers can do things like run at a preset time after start up if a schedule was missed due to power off or system suspension, and you can get more information about a failed timer with journalctl. Arch wiki has lots of good info. Still, I’m a cron guy. 🤷‍♂️ Set in my ways

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.

Much more control and integration. Randomization without tricks. Dependencies. Just a few things I used last.

I am using timers for some time now, because systemd timers are included and I don’t have any good reason to install a cron also.

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.

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.