I've become a big fan of systemd timers over cron jobs. The command itself is separated out into a service with all the isolation and journalling features of a

I've become a big fan of systemd timers over cron jobs. The command itself is separated out into a service with all the isolation and journalling features of a service. You're able to test the command and know 100% it will run with the exact same environment. You can choose to disable a timer and invoke the service manually. You can setup alternate or multiple timers for the same call. It supports all the timing options of cron and expands them. You can explicitly state cron job ordering and dependencies. I've seen too many systems where the system is only fully up after several @reboot cron jobs start in some unspecified order. Don't worry about syslog going anywhere. Journald's scope is defined at providing journalling for standard out and standard error of services. In the past this output was typically sent to /dev/null or a custom log file and if you didn't bother to specify then maybe your system would be configured to send throw it away or pipe it to a file or send it to syslog. With systemd/journald, it is collecting only standard out and standard error. It holds it in a rotating journal, and then forwards everything to syslog for any actual log management and persistence.