The author simplifies the problem a lot I think. He says there's is a quite clear line between logging, alerting, etc. -- I say there isn't. What we did recentl

The author simplifies the problem a lot I think. He says there's is a quite clear line between logging, alerting, etc. -- I say there isn't. What we did recently in a quite critical system is we had a process to scrape the logfiles -- essentially tailing them and looking for words like 'error', 'fail', 'exception', and so on (well, it was a bit more intelligent than that). Whenever something smelly happened, then we received the log fragment in email. I hear the uproar, and I must say this was not our main alerting system. This was the 2nd or 3rd fallback, because an alerting system has a lot of dependencies and complexity, and it might fail in certain (unforeseen) circumstances. Having an extra line of defense is nice, and there is a well-tested, widely-used, reasonably simple way of communicating system state (including problems): using a simple logging framework. You could write something extremely simple low-level stuff for sending alerts when the more sophisticated alerting system (with GUI, etc.) fails, but why not use something that has been tested already?