Many ITOM or ITSM tools come with built-in features for alerting and notifications and are able to send at least an email or text notification upon incidents to operations teams. But is this enough reliability to respond to and handle major and critical incidents?
Recently, we have been surprised to see more and more monitoring tools listed as alerting tools on review platforms like G2. This raises the question for us: “What makes a (good) alerting tool?” And “When is alerting with built-in means of an IT monitoring solution no longer sufficient?” In this blog, I would like to answer the two questions posed from our experience.
In general, I would first like to make a basic statement at this point: An email does not make a genuine alert notification. An email can be part of an alerting process, but only if it is traceable and “actionable”.
But before I go into details, I would like to establish a common understanding of successful alerting as we understand it. For us, an alert must be fast, targeted, comprehensible and, above all, safe. But what exactly do these terms mean in the context of alerting?
We understand fast alerting to mean that as little time as possible elapses between the event and the solution of the problem. We realize this criterion by not only relying on one medium, but by using a wide variety of notification channels at close intervals to contact the responsible persons and inform them about the problem. Also, part of the rapid alerting process is to automatically escalate the problem to the next person, group or management level in case the responsible person cannot be reached. Only when this process is fully automated and well-defined can an alert be issued appropriately quickly.
In our eyes, an alert is targeted if the problem is assigned to exactly the person who is actually responsible and qualified to solve the problem. This is achieved in Enterprise Alert through so-called guidelines. These allow you to examine incoming events in detail and thus determine who is best suited to solve a particular problem. However, it is not uncommon for the data provided by monitoring to be insufficient to alert specifically enough. This is where Enterprise Alert’s sophisticated APT comes into play, making it possible to pull in the necessary information from a wide variety of third-party systems in order to alert with pinpoint accuracy.
Alert and notification delivery tracking
Alerts must be traceable at all times, so that administrative staff can intervene in alerting processes. Or, in the aftermath of an alert, to be able to view processes in order to redefine responsibilities and adjust processes if necessary. A comprehensible alerting process also includes the ability to see at any time who is responsible for which team or area, when and how. Furthermore, it not only provides administrative staff with data for on-call accounting, but also gives employees an easy-to-access and clear platform on which responsibilities can be clearly identified.
Enterprise Alerts is your central tool of choice for performing these tasks. In over 9 versions of Enterprise Alert, we have continued to expand and perfect the aforementioned points.
At what point is built-in alerting of an IT monitoring solution not sufficient?
However, in order to answer the question of whether and for how long the individual monitoring-internal notification functions are sufficient, you must now answer a few questions for yourself.
Do you rely on alerts getting to the right admins so that problems are fixed efficiently and reliably?
You can also set up fixed rules in many monitoring systems to send mails to fixed email addresses, for example, or – if you want to go to the trouble – you can also connect other media via scripts. This may work if you have only one user who should get these alerts. But as soon as you have a second person, you have to make a distribution list out of the alerts to one person. Consequently, you no longer have an exact assignment of alarms. And what do you do at night? Waking up both (or even more) recipients is not a solution at this point. This requires alarms to be sent to on-call teams, which in the end also have to rotate to keep things fair within the team. Considering all this, you either have to reconfigure the monitoring tool daily or write complex maintenance-intensive scripts.
Enterprise Alert covers all of these items “out-of-the-box” and it only takes a few clicks to set everything up.
Do you need the ability to prove who responded to alerts, when and how? Do you need overviews of who was on call and when? Do colleagues need to know quickly who is responsible when, how, and most importantly, who is available to complete their tasks?
You can probably map all this in some way with the monitoring logs and a few Excel files. But is this way of working time efficient or easy to handle? Is it safeguarded against simple human error? Is it flexible enough to allow for last minute changes? If we are honest with ourselves, the answer here has to be “no”. Enterprise Alert addresses exactly these “pain points” and provides you with a one-stop solution that always delivers accurate information and allows for accurate follow-up even in the aftermath of major outages.
Many monitoring systems now include the ability to send messages that allow you to send at least simple notifications. In this case, however, you would rely on the fact that the colleagues on standby are really woken up by a single mail or SMS, without the safety net of a reliable and traceable escalation? The key questions here are “Does a total failure cost me more than a genuine alerting tool?” and “Can a dedicated alerting tool optimize my processes in such a way that I save more through efficiency gains than what the solution costs me?”. For many of our customers, the answer here is “yes” and we would be happy to help you answer this question for yourself as well. To do so, we invite you to simply contact us via chat or at firstname.lastname@example.org.