I recently wrote about when out crontab entries run, and in a comment Joseph asked if we'd considered switching toward systemd timer units instead. The short answer is no; the longer answer is that unlike Joseph's experience, we don't think we'd find timer units to be a significant improvement over the old, well understood crontab approach.

So let's start with the good things about systemd timer units as compared to /etc/cron.d, which as I see it are two-fold. First, systemd timer units provide an easy way to execute the actual 'crontab' command on demand; since they require an accompanying unit to activate, you can just 'systemctl start <unit>' and be done. This beats looking at your /etc/cron.d entry to pull out the command, and as a bonus it automatically gets the user right, if you're running the command as a non-root user. Second, systemd timer units provide more flexible timing for periodic activities than crontab entries do (and can have built in randomization of start times, which is important across a fleet). Crontab entries need to divide relatively evenly into crontab units, and they don't go to finer grained units than minutes. If you want something activated every 90 seconds or every 13 minutes (for two examples), using cron is going to be painful.

The great advantage of crontab entries in a modern environment that supports /etc/cron.d is that they're much simpler to deploy and use. With crontab, you need one simple file that you put into a single directory and then everything is deployed and active, and you will automatically get mailed any (error) output so you know about problems. With systemd timer units, you need at least two more complex files (a .timer and a .service file), you need to run an additional command on deployment (to enable the timer), and being emailed anything when the timer fails is more complicated. In addition, both the systemd files have to go into an increasingly cluttered directory that's used for all sorts of assorted purposes (ie, /etc/systemd/system), while crontab entries go into a directory that's specifically for this purpose (/etc/cron.d) and so is easier to keep track of.

A single crontab file can also have multiple related activities in it, such as 'everything we do frequently on our ZFS fileservers'. With systemd timers, each timer unit can only control a single command, because it triggers exactly one other systemd unit. This can increase the number of files and deployment steps you need, and also opens the door to mistakes like a partially enabled set of timers (or, on the flipside, a partially disabled set of them; with cron.d, you can 'disable' everything in a group by removing the file).

For us, the systemd timer advantages aren't important. We rarely want to run crontab commands by hand, and we don't have anything we want to run that doesn't fit within the constraints of crontab scheduling. By contrast, we do get value from the simpler deployment for crontab entries in an /etc/cron.d environment (and also from /et/cron.hourly and /etc/cron.daily).

In theory, /etc/cron.d is somewhat more universal across Linux environments. In practice systemd has won these days so systemd timer units are as available on any Linux distribution we're likely to use. They're certainly as available on Ubuntu LTS, and in practice we are essentially an Ubuntu LTS shop these days.

(We still have some CentOS 7 systems, but since IBM took CentOS 8 out behind the barn and shot it, they will be replaced with Ubuntu machines in the future.)