Everbridge IT Alerting Reviews

The primary use is to engage, to notify, and engage IT team members when an outage is underway. We do use it for proactive notifications, but our primary use is to communicate with support-group team members when we need to get their attention and fix a problem.

Some of the features we were looking to achieve included proactive notifications, for a situation where we might have a database server that has 50 databases on it. That means if I shut down that database server for patching, all 50 of those databases are offline and multiple applications, anywhere from 50 or more, are also going to be taken offline. We use this Everbridge IT Alerting tool as a "polling" product to reach out to the stakeholders of those 50 databases and give them five options of day of week and time of day, and say, "We have to shut the server down. You get to have a voice in when we do so to minimize the impact on you as a business stakeholder." We've been leveraging the product to do some of those proactive outage notifications and polling capabilities as well.

We are also striving to integrate it with other parts of our IT operating ecosystem. We already use it to communicate when a monitoring alert triggers one of the reactive notifications, and we are seeking to implement more of a full loop between that event and an incident being opened in the service management system. We're not quite there yet, but we're walking in that direction.

What we were looking at was: "How do you shorten the time to restoration when a crisis is occurring?" That's really the key benefit of the out-of-the-box Everbridge IT Alerting functionality for us.

In terms of improvements to our organization, we're still on that journey. I've used the terminology with our friends at Everbridge a few times, where I associate this with the traditional "crawl, walk, and run" metaphor. One year ago when we launched, we were barely crawling. Then we started crawling fairly quickly. I would say we're now in the "toddling" stage where we walk, but we don't walk all that well yet. For us, it is a continual improvement journey. 

We are anticipating that over the next 12 to 36 months we're going to go from toddling to walking very upright and then into running.

Organizationally, we have gained some benefits already. Even in the first few months, we recognized or realized some of those benefits that I described above around shortening the time to resolution. 

What we envision getting as an additional organizational benefit is system consolidation. For example, we've got four different systems today that contain some of the data and capabilities that Everbridge can very naturally accommodate. We just haven't moved there yet. Over time, we'll see some reduced cost in infrastructure, reduced cost in application maintenance and complexity, some improved consistency across these procedures as a result of using one system versus many. This should contribute to further reducing the time to restore service. In the end, we get benefits adding up over time, where time to restore gets better and better, and our ability to leverage the platform in multiple ways gets better and better.

We use it to alert management of priority-one incidents. The company uses it for global incidents but we have a subset of it for priority-one incidents, to let IT management know what is going on and so IT knows it's priority-one. The future is to let them know about priority-ones, twos, and threes, for the on-call schedule. But right now we're in the priority-one stage.

For the P1s especially, we had a lot of incidents where we got notifications that things were going down, and just the time it took to get people on the call - the bridge - and to get people to respond sometimes took as much as half-an-hour or 45 minutes. Now it's really down to 15 to 20 minutes. So the response time in getting teams together is much better, much more effective.

At this stage, which is step one - and we're going to try to get better - we have incidents once a week. On each of those incidents we have to do calls on root analysis and why it happened. From that standpoint, we get people on a call much faster to get it resolved much faster. In turn, the calls are becoming less and less. We're down to once a week. We want to get down to once a month.

A better response time helps you learn what's going on and how to prepare for the next time. For example, knowing that in January we had an incident where Asia/Far East went down because the things we were doing at night caused that slowness and lag time, we realized that we if changed things that we do at night in America, we wouldn't have the lag time going on in Asia. We realized that the things we were doing in America were affecting the next day in Asia.

It helps us get everybody involved, the first, the second, and treasury, where normally, to get even one person on the line was difficult. I work at night, from 7:00 PM to 7:00 AM, and that's the hardest time to get somebody on the line and get them actively involved. But they know that when they get that call from Everbridge - and if they don't answer it goes to their home phone, it goes to their cell phone - it is important that they get on. It's not just a call for general information. They know if it's an Everbridge call that it's something very important and that their manager is looking at it. That puts us in a better place. When there is a call, they respond.

The primary use case is for us to mobilize and engage our IT workforce in response to either major incidents or critical monitoring alerts that require immediate response. We run anywhere between 150 to 180 major incidents per month. We also use this for our critical ticket management, as well, which is roughly 200 more a month.

Before Everbridge, it would take us anywhere between 45 minutes to an hour and a half to mobilize our IT resource teams.  This was a manual call tree process where you are picking up the phone and calling everybody one by one. Now, by leveraging Everbridge, with a few clicks of a mouse, we are able to go in and request as many teams as we require to respond to an incident and bring them together to collaborate much faster. That 45 minutes to 90 minutes is now a few minutes up to maybe 15 minutes, depending on responsiveness or if the escalations have to kick in. We have seen substantial savings in manpower and a significant reduction in our time to respond and recover.

We have a ticketing system, Remedy OnDemand, a fairly large IT shop, several thousand servers, about 900 people or so working in IT, about one-third of them are doing support in one way or another or having to deal with incidents. So the use case for this tool was to notify teams or individuals that there was an incident in progress that they needed to attend to. Usually, it was for incidents that had the kind of priority that needed immediate attention.

Natively, Remedy will send out an email. But if you need to get somebody's attention because a server is on the brink of falling over, that doesn't cut it.

Our use case was essentially incident notification.

I was there to transition to the tool. I did all the use cases for it and then I handed off the reins of power to my successor.

For us, having a quick response to urgent events - events that were not necessarily critical but that could become critical if not dealt with urgently - was important for us.

Prior to having a notification system in place, we either had to have an operations person checking all the queues in Remedy or someone subscribing to emails from Remedy and then doing manual call-outs to people at 3 am because a server died.

We had a fairly sophisticated ticket flow. We had a monitoring system with an events co-relation and event management system that would then automatically create incident tickets. The incidents tickets, based on their level of urgency, would then be channeled out through the Everbridge IT alerting platform which would then trigger off escalations based on the urgency of the incident. For example, if there was a P1 incident where the data center was down, it would escalate much more quickly than if there was a P3 issue that you needed to look at quickly to avoid a P1.

If we were to compare no IT alerting to IT alerting of any kind, the latter makes a significant difference. In our case, we used to have real, live operators who would call people out. Now, the operations staff is there just to manage some escalations but it really removes the human from the equation, from the moment of detection to notification. 

Before, we'd have a human looking at a console of some kind and that person would then have to look up a contact list to find out who was the owner of the alert, find their number, call them and, if nothing happened, figure it out, and say, "Okay, I've got to escalate." They would then have to call the second person in line, and so on. It was not really a manageable situation. Having an alerting solution connected to our ticketing system made the flow much more effective and really did improve our overall response time and uptime.

We use this product for engagement to critical outages, so we use the smart bridge functionality. All of our entire support staff is in Everbridge. Anybody and everybody that we need to get ahold of from a production perspective is in Everbridge, and we use it to engage them. This can be both singularly as an individual or as a group, and it has a calendar that escalates up the chain.

If a primary or secondary don't respond within a given amount of time, it'll go all the way up to, in our case, the VP, which is what's required by our organization.

We also use it to send out notifications to support staff, if they have a ticket in their queue that hasn't been assigned to somebody after given an allotment of time. I think it's about 30 minutes. So, if a ticket is sitting unassigned, it'll notify that team saying, "Hey, you've got a ticket out there", and they can actually respond to that particular text message saying, "yes, I accept".

At that point, Everbridge will then tell ServiceNow that this support person has accepted the ticket, and ServiceNow will then assign that ticket to that person. So, they don't even have to log into the system in order to do that.

We also are using it under certain conditions for critical alerts. If we've got a set of alerts set up such that if one of these is triggered, something imminent is going to happen, then it will engage both a SWAT team and my incident command team at the same time, stating that a bridge needs to be set up immediately for this particular issue. Everbridge does all that for us.

It also does incident subscriptions. For example, if you want to be alerted for a given platform, for a given priority, it'll send you a notification saying, "Hey, there's an issue in your platform". We send communications through it, which are self-serve from the business perspective, stating that, again, what type of platform or application that you want to be notified on. If there's an issue in that particular platform or app, you will get the notification, again, that something is going on and all of the details thereof.

It is also selected by priority, so if you want only to know about the priority one, twos, you can select just those. Or if you want to know about the non-majors, threes and fours, you can also opt into those.

The most valuable feature is the support calendars.

In the past, in my previous company, we actually did a survey and we spent over 45 minutes trying to notify and engage personnel for any given major incident. Everbridge has managed to actually reduce that to under three minutes.

Even in my new company, our engagement time is sitting right around three minutes to engage personnel to a critical outage. This means that we don't have to spend time finding out who the on-call is, or find out what their contact information is. If they don't respond, we don't have to look up their manager or their director or their VP. Everbridge does that all behind the scenes and quickly.

We are just getting into smart orchestration, which I don't have much experience with yet but I am pretty sure that I will be learning a lot about it within the next year. To this point, it has saved us time compared to my previous experience with deployment.

Currently, we use it for two different things. One is from an intel perspective where, within VCC, we have the assets plotted. So, if something does occur, we can see where our assets are in relation to where a risk event occurs. The other one is for business continuity. If there is a potential crisis, we send a notification using Everbridge, but we use it through another program called Fusion. So, we send an Everbridge notification activating the crisis response team.

We are currently using a customized version that doesn't have all the capabilities that Everbridge normally has, and we are now transitioning to software as a service. Currently, it isn't a cloud deployment, and that's the reason why we don't have some of the data supporting it. It doesn't have data sources and a whole bunch of other stuff that I know that we should be using. We use VCC, and then we use the regular platform to send notifications, but the data isn't as customizable. Things such as data sources and stuff behind it aren't there. It still has HR data incorporated into it but not the actual data sources. I can't see why these alerts are coming, other than little snippets that show that it comes from the news or whatever the general source is. I can't actually link to it or adjust the data sources. That's why I'm encouraging them to go to the updated version because of the additional capabilities.

It's much easier to determine the impact, especially as we're developing a crisis management program. One of the things that the program was lacking and the reason why I was hired is that they need to develop it. They didn't have thresholds or criteria set. So, they were trying to respond to everything all of the time with no standards, structure, thresholds, or criteria set. Everbridge is one of those tools that you can use to identify potential impact.

It is for our Global Security Operations Center (GSOC). We use it for its functionalities. It is a part of our alerting systems. Because it's a global company, we have a GSOC and some of the functionalities that we use it for are tracking security threats, monitoring, and notifying our staff and contractors. We also use it for emergency response usage.

The product started off on-premise, then was migrated to a Software as a Service (SaaS) infrastructure.

We are in the process of automating a lot of our processes. Because it has a SaaS version, the APIs are easily integratable, and we are able to consolidate functions and vendors. This saves money, because of the downturn in the industry, as everybody is penny-pinching these days. We are able to find ways to cut back. This product is very helpful with that since it is a good tool for consolidating functions for security purposes and all of the security functions that the GSOC needs.

We use it to consolidate and remove a lot of manual processes from the enterprise notification space.

What it allows us to do is integrate with our CMDB. Within our CMDB, we have everything including the ownership, from the executive level down to operational. It enables us to quickly and easily identify who the target audience is through the subscription model that is embedded in Everbridge. It helps with targeted communication and accuracy and timeliness. On average, it saves us roughly five to seven minutes, when we compare all of the manual processes we used to have versus using the tool as integrated into our ticketing system. We send about 15 to 20 of these broadcast messages per day, on average. So the time savings are definitely substantial.