I have done stuff like this for years.
I've built up a long set of SQL Agent jobs that monitor backups, disk space and similar things. It even sets up the SQL Server Mail functions and just has to be modified for things like the email accounts and drive destinations. But it is fairly generic.
As a script when I setup a new SQL Server, I just pull out the scripts and run them.
I also can had it over to junior techs to run once it is configured for the environment. I consider it part of my toolkit.
The other part of it is to know when you have too many that it gets ignored. I do it that I get an e-mail everyday for full backups regardless of success or failure. Using Outlook rules I then filter them into a s sub email box unread. I then just do a search in the box for "failure" and if any come up I investigate why. That is a daily job.
But I setup tran log backups to only notify on failure. So if I see a message come into the box at 2P I know I need to investigate it. If I was getting them for each one, then I would probably ignore it because it is now "noise" and not something to be concerned with.
You need that balance.
A little bit of this and a little byte of that can cause bloatware.