Everbridge IT Alerting alternatives and competitors

We have it integrated into our incident management system. We also have it integrated into a homegrown alerting and monitoring solution, where it does some automation and self-healing behind the scenes. 

We are working on an email integration for our service desk, similar to how xMatters themselves have it set up. 

It provides incident notifications, subscription notifications, etc. 

We use it for triggered tasks or events. Whenever a high ticket is created, it automatically notifies whomever is on call for the ticket that is assigned to a particular group, which was really one of our first use cases for it.

We saw the value by being able to import everyone's schedule into one common central repository and have one tool for all the operational teams, or any team for that matter. It gave us the technology to find out who is on call. The incident management of xMatters' integration was another key aspect, where we could say, "You can configure this when a high ticket fires." 

We had people who would say, "Oh, I didn't get that phone call," or, "I didn't hear that message." The level of logging within xMatters is pretty extensive, which has allowed us to confirm or deny if someone is saying, "Hey, I didn't get that message." It says right here in the log that you not only got it, but you answered it and hung up halfway through the message. That was a little bit of a game changer for us because it gave us the ability to validate whether or not these messages were going out. This wasn't much of a problem previously, but it has been just another tool in our tool belt to be able to confirm that this stuff has been working as expected. It puts the onus on the engineering and development teams to respond when they have been being paged or notified.

I use xMatters logs on the operational side. The logs are not really something that the other teams use as much. We use it to just make sure the notifications are going out and being delivered successfully to individuals or teams when we are sending them out. I get a rare call or request from someone on the apps teams, to say, "Can you show me a little bit of the reporting to show me how many times that my team was notified or paged from xMatters since January?" Then, I will go in and show them how they can run those reports, but also get that data for them. They may be trying to justify additional headcount next year, or something along those lines, e.g., some teams get contacted more often than others and these teams seem to always get contacted more." They are looking for anything, which they can take advantage of, to show the volume of work or amount of times that they are getting called.

I have some folks in our reliability engineering team who have taken advantage of xMatters and integrated it with a couple of our monitoring systems, then wrote some custom code to do some notifications. It not only can receive incident data from Jira, but it can also reverse that workflow and create incidents based off of different alerts triggered from external services. So, they will see an alert fire, create a Jira incident, notify the team that is responsible for resolving that issue, and then record that acceptance or decline from that notification into the ticket. It then essentially correlates those events. In a couple of cases, we have even had some help via self-healing or automation that would kick off and run like a script to recycle a server, cloud instance, or something automatically based on that alert. After that is done, it will do a validation check. If the service is responding as expected, then it will automatically close out the ticket.

We have some standards in place for technology. These go back over 10 years, even before xMatters. Having a tool that keeps it all in context has helped. It does automatic escalation, so we bake that into whatever the on-call team is. It will contact the primary, waiting 10 minutes and contacting the secondary, then waiting another five minutes and contacting the manager, and finally waiting five more minutes and contacting the director. That has been the standard for over a decade. In the past, it required a human to do that, so maybe 10 minutes was actually 12 minutes after the first wait time. Since being automated, there has been a level of consistency. It knows, "My wait time's up. I will go onto the next person." 

It has the ability to decline. Thus, if anybody in the escalation path is unavailable, then they can hit the "Decline" option. It then circumvents that wait period. It knows, "Okay, I'm just going to go ahead and call this next person right away." That is not something that we had with the manual condition. We would need to talk to the person, wait and get their voicemail, and then wonder if they were available or not. In some instances, it has expedited the escalation. The solution hasn't really moved the needle too much on the technology here. It just streamlines it a little bit and makes a slight improvement on an existing process.

We have incorporated xMatters into our application delivery workflows for notification purposes. When deployments are made or going to be made, whether they are in a scheduled status, in progress, or completed, we leverage notifications to notify people that something has been done, is being done, or will be done. From a notification perspective, it posts messages to various teams and channels based on the condition or status of that deployment. We don't have it integrated in the pipeline itself.

There are a lot of tools that can do standard notifications. However, the one feature that separates xMatters from others is the ability for it to integrate with any system that has REST API or SOAP API capabilities.

The intuitiveness and flexibility of xMatters is very good, when it comes to customizing on-call schedules, rotations, and escalations. It allows our entire technology organization to be configured and have accounts in xMatters. We don't really use it too much outside of technology, but the ability to manage that schedule, kind of setting it and forgetting it. 

It allows us to have rotations. Folks can decide if some teams rotate Monday morning, some Friday afternoon, have different shifts, etc. The temporary absence feature is pretty widely used, so they don't have to go in and rearrange the permanent schedule, but make those changes ad hoc, saying, "Hey, I'm going away three months from now. Just plan it." No matter where they are in the rotation, it will substitute a member of their choosing. That has been very helpful.

The mobile app is now almost ahead of the game. There are some features that the mobile has that the desktop version doesn't have, such as getting a notification reminder when you will be on-call. You can set that timeframe to let you know, "Hey, you start on-call tomorrow or next week," or whatever the predetermined time frame is. You really can't do that with any desktop feature. You have to do that from the mobile app.

We use the ability to send notifications from our service desk, e.g., a lot of our operational teams notify stakeholders of outages and other things like that. Its templates eliminate or minimize any type of typos, grammatical mistakes, etc. This has brought a level of consistency to our organization as we communicate to larger management teams, stakeholders, and teammates.

Right now, the breadth of features provided by xMatters are good. I work with John a lot. We just had a call with him on Monday to talk about the next release that is coming out. We are going to set up some time next week to look at some of the feature sets that will be included in that release. Every few months, it seems like we are getting a new release. That adds something. It shows the level of commitment that the developers have to making additional improvements.

The mobile app has come a long way since we brought xMatters on board. Previously, it had lacked some features and functionality. 

Subscriptions are pretty intuitive, allowing qualifiers to say, "If it includes or contains this value, letter, or phrase, then it is helpful." Something that has been a challenge for us is the ability to add the exclude option, as part of one of those qualifiers. For example, if I said that I want to know anytime the incident priority is P1. Therefore, send me an email notification so I can be aware anytime that is the case. That is easy to do. Unfortunately, our networking team creates a P1 every time one of our store's network is down, even though it is on cell backup, which is a secondary circuit. So, the store isn't actually down. It is just that the primary is down. However, by our incident definitions, it is still a P one. This happens more often than not. 

What I would like it to do is tell me anytime there is a P1 incident, except when the ticket is assigned to this team or when this word is in the summary, but there is no exclusion option. I have been complaining about this for a couple years. At one point, we created a ticket for this with the developers to review. I assume that once enough people complain about it, they will bump it up in priority to work on. However, if not enough people think it is an issue, then they prioritize their work and work on other features and functionality. However, this is something that has been challenging for us because we have needed to find ways to work around it or just deal with it. So, I would love to see an exclusion option.

I would like them to extend the level of logging for the timeframe. There are different types of logs. Some are six months and some might be a year. We would like the option to go back so we can run year-over-year reports. I think that would be advantageous because oftentimes it doesn't extend two full years, so I can't do a comparison. Sometimes, it doesn't even extend to a year depending on what it is, so I can't go back. For example, holidays are really big for us now in terms of preparation. So, someone might ask, "Hey, can you tell me what we did last year? How many times was I notified? Do I have to staff up for this?" However, I can't go back that far with some of the data to do that. 

We have been using this solution for four and a half to five years.

It does not require any type of maintenance. There is really nothing that we need to do to care and feed it. There are always new integrations that we are working on as well as ideas of how we can use it better by taking advantage of some of its feature sets.

The technical support is very good. They are very quick to respond. I know some of their guys on a first name basis, going from our technical account manager, John, all the way down to the folks who are behind the scenes, responding to Level 1, 2, and 3 issues. They have always been very responsive when we need anything or have any questions.

I would rate their technical support at around nine (out of 10), including the online help. When you are in the application itself and click on the question mark, I love how it just provides information about the page that you are on specifically. It is always updated and the content is always relevant. I have made many comments over the years that it has some of the more useful help files and documentation compared to some of the other applications I've worked with, which is why I am rating it fairly high.

Positive

We didn't have a solution prior to this one that had this level of capability. We had communication tools (notification tools), which were very rudimentary black and white. They were very inexpensive as well, but it was just simply a list of the email addresses, potentially mobile numbers, and a notification. Then, it could send a text and email, letting people know that something was there. Separately, there was a spreadsheet that listed all the different technology teammates and the teams themselves. Then, the individual technology teams would determine what they used to manage their on-call schedule. Some people used Excel spreadsheets, some people used Outlook calendars, and some people used anything in between that they found valuable to them. There was no standard or consistency for the operational teams on the call calendars.

When we brought in xMatters, it sort of standardized it, to say, "Hey, this is what we are using moving forward. You are required to stop using your Excel spreadsheet or Outlook calendar, instead baking your information in here." 

This was initially met with some skepticism five years ago where people would say, "We have a real unique case." However, xMatters' features having different shifts so you can: 

• Create multiple or overlapping shifts. 
• Create rotations based on a recurring date and time based on the number of events. 
• Cycle first to last or last of first. 

There are a lot of options and features that surprised our larger organization. For example, with the spreadsheet, we had to go in and update it ourselves, even though it was pretty simple. Now, we literally can just go in, set this up, and configure it. We have some pretty complex teams who have third-parties that do some support for us overnight, only Monday through Friday, but even the most challenging on-call schedules were able to be configured. I think that won them over at the time, since we never had anything that managed that prior to xMatters.

We were looking for a solution like this because it was a lot of manual work, on all fronts, for teams to manage. There was no standard for the operational teams to view or find out. Oftentimes, we would get old, stale information or the spreadsheet wasn't updated in the right place. As we continue to grow, this just becomes more challenging. We also wanted to standardize our messaging and have the ability to template things for consistency’s sake, just to kind of pull it all together. So, we could say. "When this event happens, these stakeholders should know." Previously, that was always manual. We would have SOPs and processes that we would review, then we would have to craft that message up. For example, we may have an old Outlook draft that we would kind of pull up, etc.

Previously, we had BMC Remedy, but now we are on Jira. So, we were able to integrate with Remedy, and say, "When these conditions are met, automatically notify the on-call team and let them know that they have a high ticket in their queue. It requires a response." That provided a level of tracking for the operational side to be able to say, "Okay, Erik responded on his mobile phone with 'Accept.'" That would, in turn, update the ticket, to say, "Erik is now assigned this ticket because he accepted it." Once we moved over to JIRA, we lost a little bit of the functionality, because it's not as intuitive as Remedy, but we have still been able to make it work. 

The automation of our incident notification process was really useful when we had Remedy. Remedy was awful at emailing people. You would have a ticket assigned to you in Remedy, and it was supposed to send you an email to let you know. However, more times than not, the email server for Remedy would end up getting tied up and fail. Then, those notifications didn't go out or were going out really late. All of that would impact the performance of the tool itself. So, we made a conscious decision to turn off or disable all email notifications coming out of Remedy. We moved them over to xMatters. So, we can know when a ticket is assigned to a group, individual, or if it has a certain keyword. field, or property equal to something. All of that can be done out of xMatters. That has really increased the level of adoption for some of our technology teammates. There are about 800 subscriptions out there now. 

When we moved to Jira, it was able to email, but some similar things have happened where the emailing of stuff can be delayed. Most of the time, the majority of people in technology now don't really complain about that because they already have their subscriptions in place. We just had to update them to point towards Jira instead of Remedy when we decommission the Remedy servers.

I went through Launchpad, in California, for a week to get a feel for the administrative and onboarding side of things. 

We did use some folks on the professional services side to help us get it integrated with our incident management tool. Then, it was just a matter of creating some standards around it and getting buy-in from the larger organization, saying, "This is what we are going to use going forward. This is how we will do these things." 

Anytime a new teammate in technology joins the company, they need to make a request, which says, "You need to submit this request so you can get your new xMatters account and be added to the right team." It is on them to make sure they fall into the right order of on-call. So, there has been a level of training on just how to use the tool, depending on what the role has been within technology, but that has not been difficult to do. It has just been time-consuming going through the motions to get everyone up to speed.

We had a second instance of xMatters on our business continuity team at the company. They recently went in a different direction because their contract was up and the renewal costs went up significantly compared to where they used to be. So, there is a level of concern about the acquisition regarding Everbridge's potential desire to increase prices and take advantage of this very good product.

Cost is probably my biggest concern. I know the solution was recently acquired by Everbridge, and Everbridge was one of the competitors that was included in our RFP five years ago. Everbridge's costs were astronomical compared to where every other solution was, not just xMatters. 

Most of the time, Sev-1s aren't something that a tool like xMatters would be able to mitigate or resolve. We do a pretty good job with problem management, incident follow-ups, and post incident reviews. Oftentimes, we try to get ahead of those before they become a Sev-1. It might help in the lower levels, when it is still a Sev-2 or Sev-3. That way, it doesn't bubble up to become a Sev-1. However, I can't think of any specific use cases where we had a P1 incident and we were able to say, "Let's use xMatters to do X, Y, Z, and prevent that from happening going forward."

I would rate this solution overall as eight out of 10.