There is one huge advantage of cron that is usually missed with such comparisons. cron is dead-easy to create and maintain. Systemd timers make sense in certain situations, but in 90%+ of my use cases so far, the added complexity really adds up the amount of time I'm administering my systems. I've been in a situation where I needed to troubleshoot why a systemd timer wasn't triggering, and I didn't like that experience at all. To me, it is something I would use if I actually needed it, it isn't a 1-to-1 replacement for cron.
I actually disagree with simplicity. cron does weird things with the environment and it can be hard to correctly reproduce that environment when creating a job and debugging. Conversely, systemd timers are very easy to manually trigger and otherwise behave as a normal oneshot service.
We have a free tool called CronitorCLI that includes a cron-like shell. You can run and test your scripts in an environment that matches how they will be run by cron itself.
As somebody who has made cron jobs my career for the last 11 years, who left a good gig as an engineering director to build a bootstrapped business — that means a lot. It keeps me chugging. Thanks so much.
All the cron issues I've had boiled down to a difference in env vars. So testing the cronjob means reproducing the environment like this SO answer explains.
There is also one huge disadvantage of cron: it requires root. Users can create and run systemd timers without root/sudo.
And quite frankly, your experience is likely due to your personal knowledge bias. Systemd timers are quite easy to debug, in fact easier than cron in my opinion. systemctl list-timers lists all the timers, when they last ran, when they will run next, and you can use other commands to inspect each timer in detail and all associated logs.
In contrast, I find cron much harder to debug. Starting with the first problem, you must first figure out what cron is running, as different implementations have different behavior!
You cannot edit /etc/crontab without root. I'm not talking about dropping privileges for the job.
Although speaking of which, cron dropping privileges is not as secure as systemd running as the user before parsing the user's timers, from a defense-in-depth perspective.
I was unaware of that, so thank you for the education. But for what it's worth, I have never seen a Linux system which didn't have user crontabs. So even if not universal, it is at least very widespread to the point that you can bet on its presence.
Give me an example of cron, which doesn't support user crontabs? Let me list three that support user crontabs: (a) cronie is controlled by /etc/cron.{allow, deny}; when the latter files are not present, every user can submit cron jobs to crond. (b) One can set up Anacron within the user's home directory[1]. (c) systemd timer is another kid on the block; any user can create a systemd.timer unit.
