If this is a systemd distro, you can just create a timer and service. That way instead of sending a mail message, it's automatically part of the logging for that unit.
If it's a recent version of systemd, you can have a user based systemd that doesn't need escalated privileges. I just finished setting up borg for backup since I'm on Fedora Silverblue now (couldn't use the old way), and I just set up user based systemd units to do the backup.

@jaredbusch said in How to use a systemd timer instead of cron to automate a git pull:
Oh look I just found this posted here already /sigh..
So many questions I could have not asked of @stacksofplates, had I recalled this thread.
https://mangolassi.it/topic/13455/systemd-timers-instead-of-cron
I honestly forgot I posted that.

@obsolesce said in Systemd timers instead of cron:
@stacksofplates said in Systemd timers instead of cron:
Now just enable each one
systemctl enable backup-tower backup-pbx backup.target backup.timer
I'm not sure how this works.
Why wouldn't you just enable the backup.timer? Why add everything else in there?
I'm not clear on how it's all linked.
Yeah you don't. I honestly don't remember why I had it this way. Could have just been an accident. Was quite a while ago.

@matteo-nunziati said in Anacron Jobs on a CentOS 7 Server:
@JaredBusch well never considered the workload on servers. I don't know how they manage it! maybe not so many use unattended upgraqdes in debian.
I definitely feel like Ubuntu users don't keep their systems as up to date

In larger teams, you normally have 24x7 staff. So the reboot schedule goes to the current shift to monitor. It's only shops that lack round the clock scheduling that have this as a real issue, and if you don't have 24x7, shouldn't you be outsourcing to a shop that does if you really need that at all? I think that this normally (maybe not always) becomes a problem when you are dealing with layers and layers of other problems like not having enough IT staff to properly staff a department without causing unnecessary cost and risk and choosing not to outsource to an MSP/ITSP that could do this cost effectively.

@g.jacobse said:
I rant that over in my mind, and it seemed that if the reboot failed, you would not get any type of email.
If the reboot failed to run completely (like the system was down, cron had crashed, things were frozen) you would get no email either. You are making the system report on itself with is not good.
That's why the system should reboot itself (no way around that) but the monitoring of whether it is up or not should be done externally.

@thecreativeone91 said:
@thanksajdotcom said:
@scottalanmiller said:
Is the bottom portion always the same length in lines? If so, the tail command will do it.
Id have to confirm but pretty sure. How do you tail 16 lines?
Tail -16 /location/of/log.log
That did it. Perfect! Thanks!

I found a thread on the Ubuntu forums here: ubuntuforums.org/showthread.php?t=1845962
It pointed me to a conf file located here: /etc/rsyslog.d/50-default.conf
I used vi to uncomment this line:
cron.* /var/log/cron.log
Now I should get cron logs. I'll check the other place too. Thanks!