xMatters Reviews

We use xMatters as our automated on-call engagement system. We use ServiceNow for major incident management and processing for the university's IT services. When there is an incident of sufficient priority, impact, or urgency, we make use of the integration between ServiceNow and xMatters. xMatters contacts our staff members who are on call to make them aware that there's an issue going on. It gets them the information they need to log in and fix whatever might be happening. xMatters can do a lot of other things, but we use it primarily for our major incident response and automated on-call processes.

In 2019, we embarked on a "lights out" process. We had staff members sitting in our operations center, 24/7/365. They had to watch the screens and make sure, when something went "bump" in the night or something went down, to physically pick up the phone and call somebody. In December of 2019, were able to bring those staff members back into a nine-to-five type of job, repurpose them, and move them into other roles. We let the machines do the hard work of notifying people if something goes wrong. xMatters was a big part of that because it allowed our managers to maintain their own rosters, and cell phones didn't have to be handed from one person to another. The process just worked really well. That was of benefit for our central IT.

We also onboarded our institution's public safety/police department. Before, if they had an issue where everything went down and they couldn't do anything from their office, they would either call or walk over to the IT building and find somebody in the operations center, and then the operation center would call somebody from networks. Now, we have onboarded several select people from the police station. They have the ability to use the xMatters mobile app to hit a big red button that contacts our major incident managers directly, without them having to do much else. That means they don't have to physically come work with us or find us. We were able to replace that physical process that existed prior to 2019 with a fully automated process now.

The automation provided by xMatters has helped us respond to incidents. It puts the responsibility for responding on the groups and the people who are responsible for providing service. They're getting a notification when something happens that meets a certain threshold. That's in contrast to the subjective process we had in place previously where the person who was in the operations center decided not to call somebody for whatever reason. Now that it's automated and everybody is playing by the same rules, there have been improvements on the monitoring side of things and in how things are architected. They know that if something goes down, they're going to get a call. Having the managers and the people closer to the process, with the ability to manage their own rosters, results in a little bit more responsibility, rather than just passing it off to the person who's sitting in the operations center.

The automated notification process has made people understand that they have to fix things before they go "bump" in the night. They know there is no longer a person sitting in our operations center who might decide not to wake somebody up. The machines are going to detect that something has gone wrong and they're going to notify xMatters, and xMatters is going to notify the group. Tangentially, that results in people proactively fixing things ahead of time. In turn, with people being a little bit more proactive in handling things, issues don't get up to a priority-one level as much. But when it happens, xMatters does its job and gets out of the way really quickly. It helps us deal with incidents when they happen.

In addition, the targeted notifications have helped reduce response times to IT incidents. It doesn't require a person in the operations center to call five people five times. It handles things synchronously. I would absolutely posit that our response time is quicker than it used to be.

When we purchased the product, the main reason was that when an out-of-hours issue occurred, our command center teams were struggling to find the correct on-call resources. There was a great disparity between teams. Some teams had just their own Excel spreadsheet with who-is-on-call at the time, and some people used SharePoint. Some people were using AlarmPoint, but unfortunately, the old version was quite clunky. It was not very easy to configure the rotas. So, the primary reason why we initially got the product was to consolidate and have one centralized location where all on-call rotas would be stored so that in the event of an issue, the command center or any team that needs to contact an on-call resource would be able to easily go to xMatters, search the group, and then be able to contact the correct member of staff. 

We also use the tool as a notification product for different use cases. Initially, we only had an integration with our alert aggregator for the alerts coming from servers or applications for which we needed to engage a support member for a fix. We plugged that into xMatters, finding over 20,000 events a day. It allowed users to subscribe and say that if there is an alert from a particular server name and the event or alert summary contains X, Y, or Z, give them a call or send them a text or an email so that they are aware. Since then, it has grown a bit. The resilience team has now begun to use xMatters as their primary communication method. So, in the event of an emergency or a security breach, we use xMatters to contact all members of staff across all locations. We have more than 25 locations with over 100,000 members of staff. It's only used in emergencies. It's few and far between that they have to use the product, but they do send out quarterly text or voice calls to confirm that they have the right contact details for each member of staff. So, I get a text that says, "This is a B alert, xMatters message. Please confirm that you've received this message." They can then use that to keep track and make sure that they're able to contact everyone in the worst-case scenario or when they have a big problem.

We've now grown into multiple integrations of different products. We are now mainly looking at ServiceNow integration. We do have an in-house-built integration approach where we just use the APIs to pull data from ServiceNow and push it into xMatters, but we are looking at using the actual plugin. The banking world has pretty strict security regulations. The cloud-to-cloud integration needs to go through multiple different hoops, and at the moment, xMatters uses HTTP as opposed to HTTPS. So, currently, we are pulling the data from ServiceNow and pushing it into xMatters. We're not using the official plugin as such. It's just something that we've done via a script by using the APIs of ServiceNow and xMatters.

In terms of deployment, we're accessing our instance through the cloud-based solution that xMatters provides to us.

We have used coding to expand the flexibility or functionality of xMatters workflows. We've coded a ServiceNow script to use via the API to pull in data and transform it. We also have some parts of the IBM Netcool integration to make sure that we add relevant data or information that we utilize on the xMatters side. There is also some code to make sure that the workflows adhere to our standard or, at least, adhere to our document for the workflow.

We use xMatters’ REST API. It is pretty in-depth. It has been a nice feature to have. It has only been around for a year or two, and without it, it was a real struggle. They made major improvements, and you can now pull almost anything that you need to and create a report yourself via the API. You can also integrate with custom workflows that previously would've been a nightmare and required either getting an xMatters consultant on a call or paying them money. Now, with the API, we can insert any data we want. We can target whatever workflows we've worked on ourselves. Overall, it is a pretty good standard of API. You can also request them to add something. If you want to utilize something or pull some data from the API, they're quite receptive to including it in their development plans.

It has helped us to build workflows that meet our needs. The main integration with IBM Netcool is pretty important because, without it, we would be relying on other notification methods or just an email or an alert from ServiceNow which, in our experience, people tend to ignore. When there is an incident raised, making sure they get a text for specific issues is much better. So, we do rely on the product to a certain extent. I'm sure that there are other products out there that can provide the same solution, but it would take time for us to migrate off. With the flexibility of the workflows, we can build what we want on top of xMatters, which is something that we appreciate. It is the sort of thing that we can't live without anymore.

The workflows help in calling out people in the event of an issue, and they also allow us to notify key stakeholders of issues or security-related issues. From a resilience perspective, the tool allows us to send out mass notifications to huge groups of users at the click of a button, as opposed to previous tools that would have us spread across a day to contact X amount of people.

The time saved in terms of creating the rotas and manually doing that each week is about 20 minutes per week, but if we didn't have this sort of product available to create an alert when an issue happens in the middle of the night, it would require 24/7 eyes on the glass by our team members to pick up that alert, go to the rota, find out who's on call, and manually call them and get them out of bed, which could be an hour or two hours process. Even if they see it right away, it is still going to be quite long-winded, as opposed to this automated solution where teams can say that we know what we're going to get called out for, and we can configure that via a subscription, and then they automatically get a call out within a minute or two. There are big benefits to that. It could take hours before for more business-critical issues. We're now making sure that people are getting on the calls as soon as possible, as opposed to relying on humans and manual processes.

It has reduced our mean time to resolution because we don't rely on humans looking at screens, picking up an alert, and then picking up a call to get someone out of bed to fix an issue. Now, it is a completely automated process that could save anywhere from 20 minutes to two hours. That's assuming that they don't miss an alert, which is not going to happen with xMatters because it's an automated integration that's guaranteed. So, it has definitely improved the speed of resolution for specific issues.

In a major-incident environment, when the command center needs to reference an on-call rota, previously, they could have spent half an hour trying to find the correct rota and figure out who to call, and in the end, they probably have to just call a manager who would then know who's on call and call them themselves, which could be time-consuming processes. Now, if you support an application of a certain priority, you're expected to be in xMatters with a rota, and the command center can then easily reference that in the event of an issue and get hold of the right person.

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.

The primary purpose of the solution is to manage callouts to support staff for groups based on incidents created by ServiceNow. That's why we bought it, though we expanded its use since then and use it for a few other bits and pieces. We use the product's Workflows feature to integrate with Teams to get information and alerts sent to our Teams channel.

Our primary integrations are with our ServiceNow platform, MS Teams, and Slack, and for our current project, we are looking into getting xMatters integrated with Everbridge.  

We want to use the solution with Everbridge to become our incident hub for incident managers to collaborate on high-priority incidents.

The most notable improvement is in our time to respond. Traditionally, when we had high-priority incidents raised on our ServiceNow platform, the monitoring would detect them. Then a monitoring team member would contact others, take the incident assignment, and start working on a fix. Since we implemented xMatters, getting someone working on the call has gone from 30 to 35 minutes to about five minutes. That made a massive impact on our organization.

The solution helped to automate the incident notification process, and communication around incidents is much improved with xMatters, especially with the recent expansions in Teams. We can see callouts, updates, and whether callouts have been accepted or rejected, and it all goes back into our incident, so we can see what's happening almost in real time. Therefore, users are well informed of unfolding events, and the whole process runs more efficiently because the automation removes the manual element we used to have. 

xMatters helped us build workflows that meet our needs. I work for a major broadcasting company, and our most recent project was to create workflows to deliver an end-to-end callout solution for our parent company. This is important because I remember the solution before there were workflows, so it was more coding oriented, whereas now it's much more drag and drop. Coding skills aren't required to set up workflows now.   

The solution's workflows helped us to proactively address issues, as all the workflows we set up do precisely that. The guiding practice behind our workflows is to deal with specific use cases more proactively.   

The solution providing targeted, content-rich notifications reduced our response time, and that's our most significant takeaway from using xMatters. Response times are the most notable improvement from using the platform and integrating with ServiceNow. As mentioned earlier, we can get someone physically working on a callout in under five minutes, whereas it took 30 minutes or more previously. For a broadcasting company, when services aren't available, like pay-per-view, for example, 30 minutes has a huge impact.  

I've used it in two different capacities. The first one is as a user where I've had to initiate notifications either to a large group of support teams or page individuals through the tool. I did that probably four to five years ago, and then in the last three to four years, I've been using it as more of an admin where I'm building out form scenarios and different communication vehicles for our command center staff.

The biggest improvement is from the standpoint of making sure that we can use the 911 feature. Our company is realizing the benefits of using xMatters as a 911 calling feature internally. The way we use xMatters is the way you would use the 911 feature to be able to contact a call center and get the police, the fire department, and the ambulance to your house within a very short window. It provides the ability to do that. Five years ago, we had maybe 30 911 related calls a month, and now, we're averaging over 400 911 related calls a month. A lot of it is because our organization is growing so fast, but xMatters has that ability to help us when there is an emergency or an event where we need to pull in multiple teams. We can do that very quickly with xMatters.

It gives us every ability to customize as we need. We don't really have any crazy ideas of what we were expecting from the tool. It lets us cover our largest teams with 50, 60, or 70 people in a team. It lets us have multiple escalations within those teams. Multiple shifts with in the groups allow us to see any gaps or scheduling conflicts and even lets us assign a backup on-call when someone is scheduled off due to vacation or an illness, a backup solution is already there in the tool. So far, we haven't seen anything that we couldn't do in the tool related to scheduling and on-call coverage in groups.

We have currently integrated it with MS Teams as a conferencing and chat solution. We have it integrated with OMNIbus and Splunk, which are alerting tools. So far, I haven't had any problems integrating it with other tools. They give us a lot of options. We can integrate it manually by adding the links as drop-down options to integrate with those conferencing bridge lines or the MS Teams chat links. If we want to integrate through bots or through other ways, they give us multiple options. Currently, we're using a lot of manual integrations. So, we're uploading links and allowing individuals to select the appropriate integration, and then from there, they can select which conference bridge or chat they want to select from drop down values. So far, it has done what I need it to do.

We have over 350 notification vehicles for the applications that we support, and we've automated 8 of those with our alerting tools. It has helped with our more highly visible, and what we consider critical, applications. Instead of having someone to detect the alert and then send out a manual notification, we allowed our integration with OMNIbus and Splunk to automatically trigger those alerts, which has saved us 5 to 10 minutes. This allows for teams to start troubleshooting an event 5 to 10 minutes faster than they normally would. We're seeing that type of integration with alerting grow. We've received 5 to 7 new requests for automation notifications this year. So, that's going to grow. At this point, everybody who is using it really likes it. I can tell that we're going to be moving in that direction of having more automated notifications in the future.

It allows us to be aware of an issue faster. It allows us to respond and start troubleshooting an issue faster. As a result, our customers and our internal support teams are probably happier that events go away or are resolved at a faster rate.

It helped us to build workflows that meet our needs. The workflows allow us to push out multiple communication vehicles to our command center or support teams. If we didn't have the workflows that are built into xMatters, it would be hard for us to push out these large complex communication vehicles. The workflows allow us to use the same properties, same scenarios, and the same forms to push out and streamline the communication vehicles that are available to our staff. If you had a hundred people using a hundred different pieces of paper, it would be hard to maintain, but if you can have everybody using the same notebook and using the same cheat sheet, it gets easier. The workflows are like those cheat sheets. They make it faster, and they make it easier, and when we make an update, it's cascaded to all the forms and the scenarios as part of that workflow. So, it streamlines our work from an administrative standpoint.

It has reduced the response times in our organization. Since I've been here, problems get resolved faster. Because of xMatters' automated notifications and the ease of use, people can send out notifications and get together faster to solve problems. 

Its on-call schedules and streamlined escalations helped to reduce Sev-1 incidents in our organization. 

We use it mostly for major incidents. To contact, we use the group on-call schedule feature. We use it to communicate and notify our IT stakeholders and executives.

We are about to use it for incident alerting on applications. We will first start using it for one application, and then we will see how it goes.

Previously, we used to do everything manually. We used to call our on-call resources manually. If we wanted to inform someone, we used to use Outlook email. Now, it is much easier because we're using the subscriptions based on location and affected services, which is amazing.

We have the Inform with xMatters feature and the Engage with xMatters feature. We are also using the major incident feature where it sends SMS and text messages. We use it only to communicate with the IT leadership, and it is great. Previously, we used to send text messages manually using our cell phones. I'm not in the US. I live in Panama. So, when I send a message, it normally gets a different number. So, no one knew how to add my number or whatever number they get from my cell phone to their safe contact list. Now, we have a specific phone number that doesn't change. So, they know who is calling, why they are calling, or why they are getting messages. That's very good. The customization of those text messages from the web service is also great.

It has helped us to build workflows that meet our needs. The ServiceNow workflow is very good. The Major Incident Best Practices workflow is another one. For our next application, there would be a new workflow that I need to create. We are also using the Emergency Change Management workflow, but the most important thing for us is major incident management. We use it for all Sev-1 and Sev-2 incidents and almost everything related to major incidents.

xMatters workflows helped us to address issues proactively. From the Major Incident Best Practices workflow, I created a workflow directly to Teams to post a notification on our Teams channel so that everyone who isn't subscribed on xMatters can see the notification that we're sending out. It helps a lot as well. I did it myself, and it was pretty easy.

xMatters provides targeted, content-rich notifications to reduce response times in our organizations. It has reduced the response time by at least 50%. Previously, we used to call people manually. 

xMatters on-call schedules and streamlined escalations have helped us to reduce Sev-1 incidents in our organization. We can contact any person. There is a 20% to 25% improvement because Sev-1 incidents are more related to the vendor. They are not internal issues.

My team manages the xMatters platform for our company. We're not just end-users of the platform. We configure and manage the platform for our company.
So, I'm probably a superuser.

I wasn't around when they started the implementation process, but I know what they basically needed was real-time alerts. So, if somebody were to create a high-priority incident and we had something that was production-down, we needed to alert the appropriate people in order to get that resolved. If I remember correctly, they didn't have anything before xMatters, or the solution they did have was very flaky and didn't process as xMatters would. So, the use case for it was to get less downtime.

There is also the business continuity side, such as knowing what locations people are in, where xMatters is used a lot more than the IT side. For example, if there is an active shooter in a single location, you can use the business continuity side of xMatters to send out an alert to all of the employees asking them to take cover, get out, and do something, or if a building blows up or is on fire, you can send out a message through the business continuity to say that nobody comes to work.

We definitely saved money because of time to react and minimized downtime. Efficiencies have gone up because less downtime makes for better efficiencies. Auditing, reporting, and logging are helpful when an event kicks off. If everything is configured properly, when an event kicks off, we have a record. For example, we can say, "This was supposed to be sent out at this time on this date. Here you go." We also have a record of whether somebody reacted to it or not.  xMatters not only sends out an event alert; it also tells you, "I'm trying to message this person after however many minutes, and their shift is set up. This person did not respond. We're going to go to the next one." So, the escalation process for this is on point.

We have a couple of integrations. ServiceNow is one. Its integration isn't seamless, but it is as close as you could probably get in the IT world. We also use a Lenel integration, which is like a hard access deal. It is home-built though, and it is almost like it shouldn't be there.

When I first started on the team, we had an ITSM tool called EasyVista. The integration that we used from EasyVista to xMatters was a completely customized integration. We customized the xMatters side of it and the EasyVista side of it to super tailor everything down to a T, and then, a few years ago, we moved over to ServiceNow, and we decided we didn't want to do so much customization within either tool. So, we went more out-of-the-box, which produced some issues and problems. They were not necessarily from xMatters themselves. They were more or less related to the process change where we had to tell the users that this is how it's going to be going forward. It won't be the same, and we understand it won't be the same, but to enable better upgrades and less vigorous testing, we want to use more of an out-of-the-box integration. It was great that xMatters already had a pre-built integration to ServiceNow. They're a ServiceNow partner. So, basically, you install the plugin and set up the plugin for your instances, URLs, endpoints, and other things, and then you're good to go. You don't have to change form data. You don't have to change values and variables. It was a big positive.

I personally don't use its logs. Our company uses the log part. So, if we have an auditable incident or issue, or something comes up that needs to be traced and audited, they use the logs, and they use the reports and everything else that xMatters gathers during an event alert. We'll use all that information even for legal purposes. I'm sure that's happened in the past.

We use xMatters’ REST API. It is excellent for customizing processes and information.

It has 100% helped us to automate our incident notification process. Before this, we didn't have any escalation process other than a manual call to the next person.

The incident notification process has definitely affected our business in a positive way. We can now set up escalations, and we can set an alert to contact xMatters and trigger certain form data. So, when there is a high-priority event, xMatters takes over the notifications and then escalations.

We primarily use it to automate a lot of our incident management processes. We have several monitoring tools and we use xMatters as a way for teams to receive proactive notifications from those tools. We also use xMatters to send out company IT notifications around incidents that are affecting our operations.

The solution is streamlining processes for us. Before, we had to do a lot more manually. We're a heavy Slack shop and we would have to copy and paste things. It also helps to keep our ticketing tools updated, which is nice. 

Our teams are also appreciating its capabilities. We have had a lot of team reworks lately, and teams have appreciated the flexibility it gives them to make their own changes to their groups, including escalations and rotations.

xMatters has also helped to automate a lot of our incident notification process. We haven't automated it entirely because we purposely haven't wanted to do it that way. But that automation has definitely made it easier to respond to incidents. 

We send out notifications to a wide audience in IT, to let them know the issue, the status, as well as the incident start and end. We were already using a lot of what is in the xMatters incident feature, but in a custom form. It's been very beneficial, helping to bring visibility into issues, keeping us on the same page, and having data that we can all go back to. That's been great.

The automation has also helped us with our data integrity. Because we have things more automated, we do have a lot less human error and processes flow more smoothly. And we can update things a lot more quickly. That has allowed us to improve our MTTD and MTTR quite a bit. Now, we're getting to the next level and we need to look at the root. That's where we haven't fully automated the incident process, because now we're looking at the harder questions, such as what constitutes a high-severity incident. We're starting to get to those conversations and, once we get a little bit more defined there, then we can automate it.

An example where we have used coding to expand the functionality of an xMatters workflow is that the out-of-the-box Sharewell integration doesn't work for us. The custom steps we have there are a primary example of coding expanding functionality. And before there were workflows, we wrote our own scripts to do what some of the workflows easily allow us to do now. A typical example would: trigger a flow, do some work, and then send out the notifications. We did a lot of that in custom scripts and we still have some of the logic in them now. A concrete example, where we have streamlined processes, is if we have a P1 issue. We automatically select the recipients, the stakeholder groups to notify, and we set some flags on the importance of the issue. We also set which devices to notify. We do all of that in a custom step, and that's as opposed to someone having to remember to all do that and things getting missed and not being consistent.

And while we don't have as many P1s—we have mostly P3s, and fewer P2s. We have seen a reduction in P2s, but we have also seen an increase in P3s. I think that's because we have more monitoring and more systems, so people are catching and reporting more issues and they let us know. We're then making them known to make sure they get the attention needed to get them resolved.