Dynatrace Reviews

There are three major things that I look for. The first is that it is undoubtedly tier one, as per Gartner. This lowers the risk of product performance. Dynatrace has a good presence from an APM perspective, application performance perspective, where it can be easily configured. 

There are many adapters and solutions available in the market. In every organization, like ours, there are a few more built-in adapters. 

From an enterprise perspective, due to the higher cost, higher stability, and several considerations for high-level architecture, I take care of security perspectives, providing a stable solution. 

For system integrators, it is good from an operational perspective since there are many SLAs, so larger organizations generally opt for tier one solutions where they can have fewer operational issues, avoiding SLA penalties.

Graduation features offered by Dynatrace provide a single view and can connect with many other monitoring systems. Importantly, it delivers real-time insights. 

Additionally, Dynatrace positively impacts my organization in various ways.

We're a health plan, a health insurer. We're not a big one, we have about a million members. We are growing through adding new business and we're looking to expand into the government programs: Medicare, Medicaid. Right now we provide individual and family, large corporate, self-insured, and a couple other types of health plans. 

We are headquartered in Minnesota, outside of Minneapolis. We have a data center in Minnetonka and one in another suburb. We do most of our work on-premise. We don't have much in the cloud for our core backroom applications. We use a package from a company called HealthEdge in Boston, to do our claims processing, membership, enrollment, etc.

Our main use case is application performance monitoring, right at Dynatrace's sweet spot. First, we wanted to know what the performance of our healthcare and our health claims processing system was. Then we wanted to be able to segment it by where the transaction response time is spent. We also wanted to get into the deep dive of the Java profile, because HealthEdge is a Java application that runs on several JVMs. We wanted not only to get into the Java code but to get into the SQL that's created to call into the database, which is where the response-time problems are. 

We're using Dynatrace SaaS now. It's the newest version.

Since we have the OneAgent feature available, we have real-user monitoring. So not only do we know the response time and availability of the synthetic route, but we know what real users experience on our website. If our service desk gets a call, which seldom happens — but let's say you, as a member, had trouble with something — we can go back and find exactly what you did and why the response was poor. We've used that many times to find errors. JavaScript errors caused by a setting in Internet Explorer were the latest ones that were annoying the members. But members don't call our service desk and say, "Hey, your website sucks." So we have to look at the data and say, "Geez, why does Internet Explorer have these huge JavaScript errors?" And then we find out.

We found an error where developers used a Google API that was supposed to find a Medicare workshop by loading a Google Map and help a member find a place where they could go to a Medicare workshop. The API had so many calls an hour and we saw that, usually, about 45 minutes after the hour, that transaction was failing. It turned out that we'd used the 1,000 allocated calls and, when, the hour turned over, it worked again. It integrates all things monitoring, from an application perspective: synthetic, real users, and Java deep-dive.

Dynatrace provides us with a huge benefit for triage because by the time a Dynatrace problem is open, AI has identified all the components and where the response-time issue is or where the failure is. It's really mindless. We don't have to try to pull out a map and figure out how the application looks. 

And Dynatrace has a feature called SmartScape. I don't use it a lot because their AI is so good that I've never had to go dig through it myself. But if I were to go through it, it would go from data centers to hosts to processes to services and applications, to show how they're all linked together. So it has a topology view. We use that sometimes when we're doing performance testing, which is something another part of my team does. They need to know which pieces are involved and this helps them know that. 

But from a day-to-day event-management and IT operations-center perspective, the Dynatrace AI is what has identified the failing component. The dashboard has all the problems. They open up these problems, which are already events in our ServiceNow environment, and these problems have the call-path and everything else laid out in them. So I've never had to dig into the Smartscape to figure out where my failure is. The Dynatrace AI has done that for me.

What we found early on in our HealthRules environment was that the response-time problems were, 99 percent of the time, in the type of SQL that we throw at the database, because the DBAs would say, "It's not the database, it's the bad SQL." Dynatrace helped us focus immediately on that and get away from: "Is it the network? Is it the server? Is this too busy?" There are all the different things that the vendor wants to throw at you. I went up to Boston to help the vendor a year or two ago. I took them right through the code and the response times and said, "Here's the piece of SQL that makes this particular function slow." Dynatrace was able to do that. We got there in minutes. They said, "Well, your server might be too busy, it might be your network," and I could say, "No, it's none of that. Here's the response time of that transaction and here is the decomposition of it. The thing runs for 13 seconds and spends 12 seconds on this one piece of SQL. I think that's where your problem is." Dynatrace was a huge help there.

The solution has decreased our MTTR by well over 50 percent and maybe by as much as 90 percent. It enabled us to identify some things, first of all. Before, it was endless war rooms, and not really an identification. Dynatrace has driven that almost to zero. When the problem is opened, we know the root cause.

As for mean time to repair, since we know what we need to repair, we can point the developer right at it. It has decreased that by 50 to 60 percent.

It has also dramatically improved our uptime. One of the biggest problems we have with the JVMs, of course, is garbage collection and memory saturation. A memory leak will develop and Dynatrace will show the memory increasing steadily. It will create a problem and they'll work on the problem proactively, and either fix it or schedule graceful downtime. If they have to shut down the environment, they can stage through the three different servers in a type of HA arrangement. So without any disruption to the client, we've been able to fix things that would have turned into major outages of the whole environment. It's a definite help on the preventive side.

In terms of time to market, the guys who work on our web portal interface, who are in-house, were early adopters of the technology on our team and learned what works and what doesn't. Dynatrace has significantly decreased their time to market. They're not really part of the development cycle, but the way they use it and the things they say about it and the reports they've made indicate that it has probably cut nearly 50 percent of the development of their portal code.

It has also helped us with consolidation of tools. We got rid of some New Relic and we got rid of some older tool which was a great, early innovator in this space, but it was acquired by CA or Microsoft. We were still paying licenses for that and were able to consolidate it. We were about to buy a network tool to help us with ACI conversion on our network side, a tool that would mainly tell us who an application is talking to on the and network. We use Dynatrace to do that, so we saved tens of thousands of dollars in not acquiring that tool. We also took the synthetic work that we paid an outsourced company to do for us and we converted all of that. Once we had Dynatrace in the house, we could do it ourselves and that saved $20,000 to $30,000 a year. There's probably more, if I were to look at it, that I could do with Dynatrace. I have to focus on the core system right now, but I think they'll get it in the SNMP monitoring space soon, if they're not already there. And the plugins on the ActiveGates have a lot of capabilities we could use. We already monitor our VMware environment with it now.

We've started to use the Apdex score in all of our communications. It's a standard metric that's used for websites to indicate how they're performing. That idea is baked into Dynatrace and we've built on that throughout our company. The weekly service quality reports that are produced and sent via email to all Dynatrace users are starting to get some notice. They show, from the web portal side, what the Apdex is. Is it acceptable, tolerating, or unacceptable? It shows the percentages of the time of use and where they're coming from. It also shows it geographically and what type of browser most of your users are using. It shows how much of it is mobile versus desktop, which has proved very valuable to our digital experience people. Things like that are a huge benefit, and those are things I didn't even know existed when I bought it.

Our primary use cases are operational awareness, health of the systems, and impact on users. Other use cases include proactive performance management, system checkouts (as we investigate the ability to manage configuration and integration to the CMDB), some usage of it from a product perspective in terms of application usage, and I use it to manage and improve the user experience by understanding user behaviors.

We are in both Azure and AWS. We have both on-premise and cloud Kubernetes environments that we're running in. In fact, we have been using less efficient deployment methodologies. We haven't encountered any limitations in scaling to cloud-native environments. 

We have only used version 1.192 of the Dynatrace product. We have not used any previous versions.

It has improved our critical incident response, exposing critical issues impacting the environment and our ability to respond to those events prior to client impact as well as resolving those events more quickly. We have use cases where we have studied a 70 percent improvement for response times in an occurring event as well as future reoccurrences being improved.

The solution's use of a single agent for automated deployment and discovery helps our operations significantly. Oftentimes when you are looking at endpoint management, centralized monitoring teams need access to data across systems. They need to manage agents deployed throughout the organization. Remote polling of data can be helpful, but it's not deep enough, especially for APM capabilities. Having one agent significantly simplifies that functionality in such a way that it enables a very small team to manage a very large environment with very limited overhead. It provides the ability for external teams to manage it because they don't need any deeper knowledge of the application than installing the agent. They have the ability to integrate the agent into deployments and to do the work with very limited overhead.

The automated discovery and analysis helps us to proactively troubleshoot production and pinpoint the underlying root cause. We have had scenarios where we can see end user impact. One of the use cases was where we had an individual system and a cluster of nine for a content management system that was having an issue. Through Dynatrace, we were able to quickly identify the one host that was having a problem, take that out of the active cluster, recycle that application instance, bring it back, and reintroduce it to the cluster in a very efficient manner. Historically, these processes take multiple hours in order to diagnose and identify the instance, then do the work. With Dynatrace, we are able to do the work in less than 20 minutes from when it first occurred to issue resolution. Thus, there have been scenarios where you can quickly identify infrastructure issues and back-end services. 

Out-of-the-box, it's the best product that I've seen. Its ability to associate application impact, as well as root cause from an infrastructure standpoint, is by far ahead of anything that I have seen due to its ability to associate infrastructure anomalies to applications. We are still on our journey of identifying the right business KPIs to see how we can associate this data.

Dynatrace is doing an excellent job of giving us 360-degree visibility of the user experience across channels in most technologies. We are working with Dynatrace to expose the full transparency to the mainframe, as we have transactions that call from the cloud onto the mainframe and back out to other services. This is a critical visibility that isn't there yet. Otherwise, with a lot of the cloud and historical systems, we do see a lot of transparency of transaction trace across the environment.

We use it for infrastructure monitoring and real user monitoring on our website, i.e., monitoring how users interact with our website and digital experience. We use it to track if our website is up using synthetic monitoring, which we use for our website and mobile app. We use Dynatrace to track complete observability through our infrastructure to our digital apps. 

We are able to share information easier and improve user experience.

When a ticket is logged in Dynatrace, it automatically goes to the correct support team. There is no manual intervention, which saves time. We are saving probably $30,000 to $40,000 annually because we are not employing several people to do this work.

Dynatrace’s ability to help us visualize and understand our infrastructure, and to do triage, is very good. It provides a Smartscape view, which gives us an overall view of the topology. When a problem is raised, it draws out where the issue lies and also suggests the solution. This brings down mean time to restore very quickly, helping the resolution.

The fact that the solution is a unified platform has very much changed the way our teams work and collaborate. It brings teams together, because they are able to screen share, especially during COVID. Then, we are able to talk about the exact same thing.

The automated discovery and analysis help us to proactively troubleshoot production and pinpoint the underlying root cause. If we are seeing error messages in our website for users who are seeing an error page, then we are able to go into the user's session, look at PurePath and the code, and see the reason why this is occurring in the back-end code.

If a user experiences an issue on their mobile, e.g., where they can't generate a ticket nor generate a benefit from our application, then it will automatically log a ticket. That will then feed into a database where the customer is contacted proactively.

Dynatrace uses a single agent for automated deployment and discovery. This helps our operations because we can bake that into an Amazon Machine Image (AMI) and roll it out.

The solution gives us 360-degree visibility of the user experience across channels. This is important in our environment. This helps us meet business goals because we are able to interact and serve as many teams. So, product managers and project managers are able to give metrics or data feedback to any team suitable from a developer to the C-level.

When we started with Dynatrace we were an on-prem organization. We used it in the early days as an APM, the way most people used it.

Our usage of Dynatrace has grown over the years, not as much in terms of capacity as in usability. It is now used by three departments within our organization. It originally started with just my group, which is IT, and then we rolled it out to development because they saw the advantages of being able to identify code bottlenecks in existing code. We've rolled it out to operations and they use Session Replay to troubleshoot customer-specific issues. And the sales department also uses it to gauge productivity and how many visits we get to a particular page, how many times people watch a particular video, how many take a certain practice exam, etc. 

Those use cases are all in addition to its core use, which is to help us keep our infrastructure running. 

We're currently using the Dynatrace SaaS, the Dynatrace ONE product. We're not using anything in the old, modular product. It fits very well for us. We are a cloud organization. We're all Azure now. We migrated from on-prem to cloud about three years ago.

The automated discovery and analysis definitely help us to proactively troubleshoot production and pinpoint underlying root cause, both from a code perspective as well as an infrastructure perspective. When we get an alert, or we're seeing a degradation in performance, Dynatrace will lead us down the path: Where do we need to look first? It will tell us that it has analyzed so many trillions of dependencies and that it thinks that the problem is "here," and it will point to a query or a line of code or perhaps to a system or to a container that is not functioning properly. Depending on what the problem is, it saves us an enormous amount of time in troubleshooting and identifying problems.

I estimate it has cut our mean time to identification at least in half, if not more. Before, we were relegated to combing through logs. We would take Splunk, look for the error, find out where it was occurring, how many times it was occurring — do all that type of investigation that you normally need to do. We don't have to do that anymore because it's all automated. 

And as far as decreasing our mean time to repair goes, it's closer to 60 to 70 percent. The reason is that we don't need to take such drastic troubleshooting time. We take its recommendation, and the time that we spend is checking that Dynatrace was right. We'll test out a quick fix in dev and then take it to QA and then push it to production. In some instances, it does reduce our MTTR by anywhere from 60 to 70 percent, although it really depends on the problem.

I operate an entire stack on four people, and the only way I'm able to do that is by automating as much as I can and having tools that I can rely on to reduce time-dependent tasks. Dynatrace has allowed me to function and keep my people productive without working them 24/7. Dynatrace works 24/7 for me.

Another thing that Dynatrace gives us is very deep visibility, not only into user actions but systems interactions. How are the systems relating to each other? Are the right systems talking to the right systems? When we first deployed Dynatrace five years ago, it showed us, through its Smartscape tool, that we had servers talking to servers they shouldn't be talking to. That was quite an eye-opener. I've noticed that a lot of companies are trying to copy what Dynatrace came out with in its Smartscape, but to me, it is the best visualization tool of your app stack and network that you'll ever put together, and you don't have to do anything. The system puts all that together. You deploy your one agent, it maps out the system, and you can see everything from application to network to infrastructure connectivity. It depends what you want to see, but it's all Smartscape'd out. You can tell what traffic is going in which direction and where it's going.

In addition, when I first started using Dynatrace, I had a routine. I would come into the office early and go through all of the night's activities. I would check for any problems we had: Was anything broken, were there any active alerts? With Dynatrace Davis, I started getting those reports automatically, through Amazon Alexa, and I do that on my drive to work. Instead of having to go in early and spend time in the office, I'm able to stay at home a little later, have breakfast with the family. Then, when I'm in the car, I invoke Alexa to give me my Dynatrace morning report, which will include my Apdex rating, any open problems, and a summary of closed problems. It's probably one of the least advertised aspects of Dynatrace, and one which I think is among the most highly efficient tools that they offer.

The amount of time we have to devote to maintaining Dynatrace is next to nothing. The time that we spend in Dynatrace is actually using it. We're using it to look at what's happening, what's going on, is something broken, or do we have an alert? We go in to find out what's wrong. Maintaining it is really almost nonexistent.

Another advantage is that it is much more of a proactive tool than it is one for putting out fires. Of course, it helps us tremendously if we have to put out a fire, but our goal is to never have a fire. We want to make sure that any deployments that we put out are fully tested in all aspects of use, so that when things are fully deployed, there isn't any need for a rollback. In the last three years, we've had to roll back a production deployment once. I don't attribute that all to Dynatrace, but I attribute a large part of it to it.

It has increased our uptime because we find out about problems before they're problems. The one goal that my team has, above anything else, is to know about problems before the customer does. If the customer is telling us there's a problem, we have failed. We are so redundant and so HA-built, that there is absolutely no reason for us not to be able to circumvent an issue that is under our control, and to prevent any type of a work stoppage or outage. We can't help it if the internet goes down or if Microsoft has a core problem, but we can certainly help by making sure that it's not our application stack or our infrastructure. I would estimate our uptime is better by at least 20 percent.

In the end, it has decreased our time to market with new innovations and capabilities, because anything that reduces time-to-produce decreases time to market. Once the code has actually been developed, it's in testing and deployment and that's where my window of efficiency is. I can't control how long it takes to build something, but I can control how long it takes to fully test it and deploy it. And there, it has saved us time.

Before we had Dynatrace, and a lot of the processes that Dynatrace has helped us put into place, everything was manual. And the more manual work you have, the more margin for human error you have.

My use cases are typically working in conjunction with our business partners. For the most part, I get questions from the business as to what our conversion rates are on the eCommerce website. E.g., what the typical user journey looks like, especially when they're doing AB testing. They like to sort of double verify that in Dynatrace with a user session tracking to see which users are taking which path. 

I often get diagnostic questions about things like latency. Somebody on the business side will perceive some latency on one of our pages, then give me a call to use Dynatrace to go in and do a waterfall analysis of the page load to see if it is in fact loading more slowly than it has been in the past.

Since we are a 24/7 support shop, our primary job is to make sure that revenue keeps going in through the site and the site itself works. We have categorized issues into three tiers: Priority 1, 2, and 3. Depending on where a given issue falls, the Dynatrace alert is generated and sent to my team, then prioritized into one of those three categories. The response then to that issue will fall into a bucket for that type of priority. 

My primary use of the tool is to keep revenue coming into the business and to use it to help our business team in running their site analytics and web performance tools. They have things like Adobe Analytics that provide them with one layer of data. We use Dynatrace as another railroad metric to both confirm the Adobe Analytics data and enhance it in certain places where Adobe won't give us the answers that we need. In terms of metrics, we've had roughly about 120,000 unique sessions per hour on our website. So, we're capturing a lot of session data and real user data, and all of that data is kept in user sessions. We can look this information up by user ID to tag any given session that we want to find by date/client. E.g., if the user said that they had an issue last Thursday at 11:00 PM, then we can just do a search on their email address, go through all their sessions, and find the one that they mentioned, then dig directly into that one.

It has completely transformed the way that we do eCommerce from a couple of different perspectives. The first one is that we are really tied in with our business users to a much greater extent than we were in the past. A lot of the Dynatrace data is data which not just the technical team wants to see and to work with, but it is data that the business team wants to see as well. It has sort of facilitated a better communication stream between my business partners and my team to allow us to go back and forth on different aspects of the website. We didn't have that in the past. 

It has also built more solid relationships between the application development team and my support team because they will often have questions after new releases as to how those new releases affect different areas of the site. So, we have constant sessions with those guys in standing meetings on a biweekly basis to go through different aspects of what a release has done to the website, how we can use Dynatrace to track differences from one release to the next, and see if there is any latency as a result.

It's used in two major use cases:

1. Monitoring and our own internal IT operations. 
2. We provide our customers access to Dynatrace tenants so customers can also leverage developing their code running on our platform.

It does full stack monitoring for internal operations, problem diagnostics, APM use cases, and performance management for our customers.

We have multiple instances of Dynatrace running, where about half of them are running in our data centers and the other half are running in the public cloud. Therefore, it's a hybrid deployment. We use a mixture of cloud providers, including AWS, Microsoft Azure (running Kubernetes), and Google Cloud Platform.

We have traditional deployments on VMware virtual machines as well as running stuff in the cloud. We have a couple hundred Kubernetes clusters monitoring using Dynatrace. Dynatrace's functionality in this area is unmatched combined with its full stack visibility, ease of deployment, and completely dynamic changes. The container environments are also dynamic since you have microservices spinning up and down as you go. I have never seen another tool doing this with the same reliability. 

Dynatrace has improved our organization through operational support. We also have a large services organization which directly works with customers, and sometimes you run into situations where customers ask how they can improve their applications. Traditionally, these service teams would go for assessments. Eventually, they would even go onsite and through performance workshops with them to find some low hanging fruits that could address, and this was very tedious work. By introducing Dynatrace, you suddenly have real-time data. Then, the process of doing performance reviews switches from workshops or a defined time frame analysis (and then taking actions) to a more continuous approach where you constantly have Dynatrace performance data of the landscape. 

Service engineers save a lot of time because they can just go in look at the data and share it with the customer, who has the same view, and say, "Here's an improvement which can be immediately implemented." It's not like a collection of big, multiple findings that are consolidated into one results presentation, then the customer needs to do something. It's more like a continuous performance analysis and improvement process, which is more efficient than those workshops approaches. That's one of the biggest of the advantages that our services team sees because it helps DevOps to focus on continuous delivery and shift quality issues to pre-production.

Dynatrace is tightly integrated with ITSM. It's integrated with ServiceNow, which our support team is using.

We provide a platform, then the customer ships the code and deploys it. Therefore, we rely on testing by the customer, and sometimes, they miss something and it breaks. Then, it doesn't work as expected so we have to step in, and say, "Yes, your site is down," or "It's not functioning properly." We do the analysis because typically the customer says, "Okay, it's not us. It must be you as the service provider." This is where we gain a lot of efficiency. The support team is the first line of defense there. They get the information to determine if they are able to quickly pinpoint the problem. E.g., the customer deployed, then two hours later, issues were occurring. This is when you don't want to waste time. Our support engineers need the visibility so they can immediately be able to communicate to the customer, saying, "Yes, it's on our side," or "It's on your side." If it's on the customer's side, they can let them know exactly where they need to go. This is where we gain most of the time.

It helps our operations that the solution uses a single agent for automated deployment and discovery. If you think about all the work in the past where we had different agents, tools, or scripts deployed to monitor specific aspects of an environment and different tools, then having one agent definitely helps. For example, for our rollout, when we migrated all the different tools to Dynatrace, we did this over the weekend. We installed the agent, then just watched the data and findings coming in, which was a huge benefit. We installed one thing an it discovers everything.

I suppose the solution has decreased time to market for our individual customers with new innovations/capabilities. Dynatrace helps them gain better insights, allowing them to do another deployment faster.

We use it to follow up user experience data. It's all banking applications. For example, when you're viewing your account, you open up your mobile app and the click you do to view your account is measured in Dynatrace. It's stored and we are checking the timing at each moment. 

We are also following up the timing differences between our different releases. When we have a new version release, we are already checking within our test environment to see what the impact of each change is before it goes to production. And we follow that up in production as well.

In addition, we are following up the availability of all our different systems. 

And root cause analysis is also one of the main business cases.

So we have three main use cases:

1. To follow up what's going on in production
2. Proactively reacting to possible problems which could happen
3. Getting insights into all our systems and seeing the correlation between these different systems and improving, in that way, our services to our end users.

We use the on-prem solution, but it's the same as the SaaS solution that they are offering. They have Dynatrace SaaS and Dynatrace Managed, and our is the Managed. Currently we're on version 181, but that changes every month.

The dynamic microservices for Kubernetes is really value-added because there is a lot of monitoring functionality already built into Kubernetes Docker. There are also free things like Prometheus which can display that. That's very good for technical people. For the owner of the pod itself, that's enough. But those things don't provide any business value. If you want business value from it, you need to extract it to a higher level, and that's where you need the correlations. You need to correlate what is between all these different services. What is the flow like between the services? How are they interconnected? And that's where Dynatrace gives added value. And the fact is that you can combine these data, which are coming from Kubernetes, and include them in Dynatrace, meaning you have a single pane of glass where you can see everything. You can see the technical things, but you have the bigger business value on top of it, as well.

Before Dynatrace, we were testing just by trying out the application ourselves and getting a feeling for the performance. That's how it very often would go. You would start up an application and it was judged by the feeling of the person who was using it at that moment in time. That, of course, is not representative of what the actual end-user feeling would be. We were totally blind. We actually need this to be able to be closer to the customer. To really care about the customer, you need to know what he is doing. 

Also, incidents are resolved much faster by using Dynatrace. And that's for front-end, because we actually know what is going on. But it's also for server-side incidents where we can see the correlation. Using this solution our MTTR has been lowered by 25 percent. It's pinpointing the actual errors or the actual database calls, so it goes faster. But, of course, you still have to do it. It still needs to be implemented. It doesn't do the implementation work for you.

Root cause detection, how the infrastructure components interact with each other, helps. We know what is going wrong and where to pinpoint it. Before, we needed to fill a room with all the experts. The back-end expert would say, "I'm not seeing anything on the back-end." And the network expert would say, "I'm not seeing anything on the network." When you see the interaction between the different aspects, it's immediately clear you have to search in your Java development, or you have to search in your database, because all the other ones don't have any impact on the performance. You see it in Dynatrace because all the numbers are there. It really helps with that. It also helps to pinpoint which teams should work on the solution. In addition to the fact that it's speeding up the process of finding your root cause, it's also lowering the number of people who need to pay attention to the problem. It's just a single team that we need to work on it. All the rest can go home.

It has decreased our mean time to identification by 90 percent, meaning it only takes us one-tenth of the time it used to, because it immediately pinpoints where the problem is.

Dynatrace also helps DevOps to focus on continuous delivery and to shift quality issues to pre-production because we are already seeing things in pre-production. We have Dynatrace in our test environment, so we have a lot of extra information there, and DevOps teams can actually work on that information.

Finally, in terms of uptime, it's signaling whenever something is down and you can react to the fact that it is down a lot faster. That improves the uptime. But the tool itself, of course, doesn't do anything for your uptime. It just signals the fact that it's down faster so you can react to it.