Video: Your Opsgenie Migration is the Path to Proactive Reliability | Duration: 5400s | Summary: Your Opsgenie Migration is the Path to Proactive Reliability

Transcript for "Your Opsgenie Migration is the Path to Proactive Reliability": Thanks for joining in, everyone. Welcome to the webcast. Your Opgenie migration is the path to proactive reliability. Just to set some context, you're in the right place if you are a standalone Opsgenie user who's paying the option to move to Jira service management or JSM. If you're a bug on Opsgenie user who also have lessons for JSM, then you're in the right place. Or if you are, if you are a customer or if you're a prospect just evaluating Opsgenie, then you're in the right place as well. I will call out, though, if you are trying to understand what incident response is, we have a bunch of talks that I'm going to link in the chat below for you to go through. If you're also looking to understand how does cybersecurity incident response differ from IT incident management, we have also clarified that in the in the talks that I will share in the chat below. And if you're just curious, if you want to just see and enjoy the demo, then we have something for you ahead. I will also set the agenda for today. So we are first gonna talk about how does how does Opsgenie's end of life play out and how it's going to possibly impact you. We're also going to talk about the dev ops and internal dev ops team here at SolarWinds who has moved from Opsgenie to SolarWinds instant response. That entire migration was led by Chase, who I'm going to introduce in a quick minute. I will give a call out, though, previously before before SolarWinds acquired SquadCast. By the way, SquadCast is now called SolarWinds Instant Response. Teams here at SolarWinds did use did use Optioni, but we are a firm believer of dogfooding our own tooling. So now teams at SolarWinds use SolarWinds incident response, formerly SquadCast. Some housekeeping as well. If you have any questions, feel free to drop them in the chat. We're happy to take them. And And if we don't have an answer to them, we will get back to you in a short minute. Also, what I would love is if you would want to, see any specific content or if you need any specific support around the migration from Opsgenie, please take this over here, let us know right to us, and we would love to talk about it in any upcoming webcast. I'm gonna now quickly talk about myself and my co presenter here, Chase. So if you regularly log in to SolarWinds webcast, then we are new faces for you. I hope you see more of us in the future. So this is Sanj. I am a newly minted product marketing manager here at SolarWinds. My team was acquired by SolarWinds. I was part of the ScottPass team earlier. And since is not SolarWinds instant response, I am also a part of SolarWinds. I will be your moderator today, your navigator, someone who's just sort of giving filler content here. Before, I introduce Chase, just some context again. He has led the entire migration office team off from Opsgenie. Chase, over to you. Can Can you talk a little bit about yourself? You're the designated expert here for us. Yeah. Absolutely. Like Sanjed, my name is Chase. I've been here with SolarWinds for about a year and a half, little over a year and a half now, working on our internal DevOps team. So we're not a traditional DevOps SRE team in the way that you would think of them. We don't support SaaS applications. We support our internal developer tooling. So things like GitHub, our CICD platforms like TeamCity and Azure DevOps, and then, like, internal package storage, things like Artifactory. We're 15 or 16 engineers distributed globally. We have people in The Czech Republic, in The Philippines, all across The US. So something like Opsgenie was really necessary for us to make sure if we get some of these alerts coming in, they can be properly routed across the globe. So our main use case for Opsgenie was just that on call notifications and routing. We used it in a pretty simple manner. Yeah. James, quick question here. When did you hear about the or when did your team hear about the end of life announcement? Yeah. Back in, March, one of my coworkers had dropped a link to the blog post or website that they had set up, dropped it in our chat, and it was, like, immediate flood of the the face palm emojis. Like, everyone knew the headache that was gonna be coming with having to move off of end of life software. So we realized we had two years as, you know, decent amount of time for something like this. So we kinda all just went, we'll figure it out when we get there. I think talk of the SquadCast acquisition was starting, so we're really, like, fingers crossed that we wouldn't have to find a brand new tool we could just use around. And then luckily, things worked out. So here we are. Yeah. No. That's amazing that Scott just came solo when the incident response just came in and helped you save today. I will also say that I think a lot of people felt the pain that your team felt because Opsgenie has been deeply embedded in people's systems for a very, very long time. It's one of the first, on call alerting tools that sort of came in the space. Talking a little bit more about how the end of end of life announcement played out. So like Chase said, you know, earlier this year, Opgenie, Atlassian rolled out the fact that Opgenie's end of life is incoming. And if you're a stand on Opsgenie user, you have to go ahead and buy, JSM or Jira service management licenses. If you are somebody who has, both an Opsgenie license and a GSM license, you will be pushed or forced to migrate to GSM altogether. Quick question, Chase. Were you guys, a stand alone option user, or did you have GSM licenses? We were stand alone. So we, like you had said earlier, we like to dog food at SolarWinds. So we were using SolarWinds service desk. We didn't have a need for Jira service management, so we just had stand alone Opsgenie licenses. Yeah. Yeah. Yeah. Thanks for that. I will also quickly add here that there has been a lot of confusion around this migration. So although the official announcement for consolidation of Opsgenie to JSM went about in 2025, in early twenty twenty four, a lot of customers saw optionies functionality show up in JSM, and that caused a lot of confusion even in Atlassian's community. Then there was a lot of talk about the migrator coming out in the mid of mid of June of last year June 2024, and then that's what got pushed pushed around quite a bit also. So what I'm coming at is there has been a lot of my there's a lot of confusion on the migration. And I think, later half of this year or next year, we'll continue to see the push around, migration. And, optionally, right now is in, complete maintenance mode. And by the 2027, we are going to see, option e being essentially being shut down. Now what I wanna talk a little bit about here is you're in the right place if you are currently a standalone Opsgenie user, much like Chase's team was. Because you're essentially going to be paying a premium if you are being pushed into GSM, which is a ticketing first platform. And now these costs can really add up if you have a big team. This also especially sucks if, like Chase said, you know, that if you're using soloing service desk for your ITSM or if, let's say, if you're even using service now for your ITSM, then being pushed into an ITSM first tool is just completely unfair. This also brings me to my second point that ticketing first platforms can be cumbersome for ops first teams to use, because they are they're optimized for customer workflows and not so much engineering workflows, which is you are a level ops engineer. And I know you have some very strong opinions about this one. We've we've talked about this before. Yeah. My, this is my opinion again. Right? But I think that really effective ops teams don't rely on customer supported issues to, like, drive their incidents. I think if the first time you're hearing about or learning that, some platform that you support is going down, if that's coming from a ticket from a customer or someone that you support, your automation around, like, monitoring and observability is probably not the best. For us, we use SolarWinds observability, both self hosted and SaaS. We still use Loggly for some things. I mean, we have even, like, Gen one product set up. So we get our alerts directly from these automated platforms. So having a service that's designed around, you know, customer reported issues and, like, ticketing first, it wasn't gonna be what we needed. We needed something that was really driven by those automated toolings the way that SolarWinds instant response is. Yeah. Yeah. I know. That's a good point. And that's a good opinion to have, I think. I also I also want to say that, you know, hey. If you're if you're a JSM user who's happy with the consolidation, you know, you're happy to have your service management and on call and service delivery order in one place. That's fine. But on call first or ops first tools should not be clunky. You know, on call scheduling and rotations are complex and manual as we see in Opsgenie or or or GSM today, which is you've you've been an Opsgenie user, and you've done dealt with the clunkiness of the on call. You've also been a solo and instant response user, formerly Spotcast. What do you think about that? Yeah. We, whenever I first got on to the team, and you, you know, you kinda get onboarded. Here's all of the tools. Here's logins for everything, you know, get set up with your SSO. Opsgenie was one of the platforms that I was kind of directed to as, you know, make sure that you're aware of this, check your schedule, see when you're on call. So I pulled this up. I had never used Opsgenie before. Pull up to try to figure out, okay, what am I responsible for? What's my schedule looking like? I'm not personally a fan of the layout of the scheduling. I thought it was really confusing as a first time user trying to figure out, okay, I see that this team is on call here. Does that mean everyone's on call? Is that just me? What's the actual schedule? What time zone is this? Because I was like, am I on call till 8PM? Oh, never mind. That's a different time zone, like, that I'm looking at. So it was really confusing, and it was kind of hard to navigate whenever I first got in there. And it it just I mean, it hasn't gotten a major update in a while. So, like, the even just the UI is a little bit outdated. Yeah. I don't think platform has it really evolved since it since it last year acquired it back in 2017 or '18. Yeah. So I hear you. And I also think that, you know, when you when you think about on call as an experience, on call can never be made easiest, so to speak. It is on call. Let's say you're like, you're there to sort of react. Right? But any good ops first platform should be able to give you clear dynamic and essentially effortless on call scheduling and, like, a rotation exportation experience. You know? Do you want to talk a little bit about how was the, alert noise with Opsgenie? How did you guys deal with that? Yeah. So part of that getting onboarded for the first time and trying to, like, look around, figure out what's going on, is just this daunting single queue of alerts, and there was sort of some tribal knowledge. Luckily, like, I have good coworkers. They brought me on pretty quick, but there's this tribal knowledge around, hey. These types of alerts, you know, don't worry about them. They're not they're kinda false positives or more informational, and it's just a single queue of alert. So they all know what this alert means, but me as a new person, I don't know what service is affected. I don't know where to go to troubleshoot this. The noise reduction in general, I found lacking. It's it's there. They have suppression rules, but you kinda need to know what you're wanting to suppress. It's not very intelligent. So if you want to suppress this one type of alert that has this name, awesome, super easy. You can throw it in there. But it was weekly. We would have new alerts pop up. We would go, okay. We need to suppress that one. We need to suppress that one. So it was just a constant, like, false positive hunt there. Yeah. Yeah. I think on your point about intelligence suppression. Right? So how at least we look at, an ops first platform here is that, you know, it should be able to intelligently correlate, suppress, and also deduplicate, without which there is so much noise. What you just said, right, the entire experience. And the problem with noise is that it can be frustrating. Over a period of time, it's gonna burn you out. And, you know, when you're like, what you said, right, when so many alerts are queued up, there's only there's only so much that you can look and look into. After a point, you're just going to sort of double up a sense of nonchalance and be like, hey. I'm gonna look into this later. And then that, you're gonna probably miss out a really important alert. So Yeah. It's the it's the boy who cried wolf. Like, if nine out of 10 alerts are false positives, I'm gonna assume that the tenth alert is probably a false positive until we have customers or our internal engineers coming to us saying, this thing isn't working. Oh, sorry. I ignored that alert. Like, I'm just used to them being noise. So, it really, like, got to the point where we had alerts just sitting open for days because we've assumed they were false positives, and a lot of our outages were reported by our engineering teams. Yeah. Yeah. No. That's fair. And I think just for the audience here, you know, if your team is spending a lot of time dealing with noise, then you you should really ask the question as to how you can change and improve your processes because that is massively going to be taking away from your team's productivity. Chief, do you I know that your team also had issues with a lot of context switching, while you were addressing incidents. Do you wanna talk a little bit about that? Yeah. So, I mean, in a a day to day, we're working in our IDEs. We have Teams or Slack open, meetings. Again, most likely gonna be in Teams or Zoom. We're checking our ticketing both on service desk and, like, our regular ticketing service. We already have enough tabs open. With the way with the lack of information we got with Opsgenie, how I was talking about that single queue that's kinda hard to identify what goes to what. Anytime that we got an alert, we were always immediately, you have to open up Opsgenie and maybe go to the service that reported the incident to figure out what's affected. It was really difficult for us to identify that root cause just from, hey. You have an on caller. It always meant switching to Opsgenie, figuring out if it was a false positive, figuring out where it's coming from, what services it's going to. 30 of just identification, and then you can start fixing it. Say it's a false positive. You just spent thirty minutes trying to discover this. Now you have to get back into the flow of the task that you were just working on. Maybe you were in a meeting. Maybe you have to go back to your IDE or to whatever, project that you were working on. It ended up wasting a lot of time for us just to go and identify is this even a valid alert, because of all of that context switching. Yeah. That's fair. So so what I hear from you is you were trying to address the incidents from where you from where you work. You were not trying to sort of have, like, multiple things go go at once once when you're trying when you're in the midst of the incident. Right? So you want to be able to address from where you work. I hear you. Yeah. Yeah. Yeah. Okay. A little bit you know, we know that looking back at incidents and retrospectives are a big part of continuous learning, especially for, for an ops first team. What were your challenges with that, when you were using Opsgenie? Yeah. I'm gonna sound like a broken record. We had just a lot of alert noise coming in, and we always had this sort of false positive hunt around these. So because all of the noise reduction was very manual for us, that meant more work whenever you want to kind of quiet things down. So there was always another task coming out of, any of the alerts coming into our queue. Part of that was in any attempt at a retrospective. Say you wanna do a once a week review of all the incidents that happened last week. Well, if you have 60 incidents and 55 of them are false positives, it takes a while just to figure out what you're even reviewing with your team. Right? So we would try to take that time to, like, go and suppress new alerts, but it was just it was a very manual process, and it took a lot of time. So we ended up just developing, like, some bad practices around that of maybe not doing retrospectives, maybe not doing these reviews because it was just a pain for all of us involved, and I don't think anybody really wanted to do them. I'm not sure if anyone ever does, to be fair. But, yeah, it just it it wasn't a very, effective or productive practice for us. Yeah. And and I think just to add, right, retrospectives, can only become retrospective if you have if you're really able to go back and really find the true root cause of something. And that can only happen once you have, like, a clear timeline or, like, a clear view of what has really panned out. Right? And from that, you sort of get your actual items, and then you can sort of incorporate that in your learning. Okay. Jeez. That's great. And we've heard a lot about the pain points that your team sort of went through. Now I really wanna move into, talking about how did you deal with those pain points. You know? And I know that you've dealt with a lot of, the pain points, and you also built a lot around, with so relevant response. Do you want to walk us through a demo of how your team is using, Sullivan's instant response today? Yeah. Absolutely. So one of the first big pain points that I talked about today was scheduling and the perspective as a new engineer trying to figure out when you're supposed to be on call, who's on call, that kind of thing. So this was a big, improvement for us was the just this even just the view of scheduling. So this is our, like, kind of day to day business hours with some weekend coverage schedule. I mentioned earlier my team is global, so we have people in EMEA, America, and APAC time zones. So you'll see down here, we have all three of those teams kinda mentioned on this schedule. And I'll scroll to where we are right now. It's 10:00 my time, but you'll see this it tells you right here what time zone ran. Either way, it's gonna tell you right now, it's Thursday. You're at the beginning of this on call schedule, Just to kinda give you that view of who's working right this second, I can pull this one up pretty easily, and it'll tell you what team is there, give you a little preview of the members. But if you wanna see everyone, pop up the profile. I can now see everyone that's currently working on call today. Yeah. We also have some weekend coverage on the schedule. That one's very easy to see as well. You know, we have two senior engineers that rotate back and forth on our weekend on calls. Say someone's sick this weekend. We wanna come in and override it. You don't need to search for some special, tab or view. We just click on this on call. We can click the override and decide who we want to assign instead. So this has been, like, a much easier view for us to be able to come in and just immediately know who's on call right now, who's on call tomorrow, what time zone are we in. This has been a big improvement for us. I love seeing how teams are set up, soloing to respond within their environment. So it's super cool to see that. I'm also sure it's super cool for our audience to see that. I love that. I can see that you've set up global scheduling. What happens if an incident is unacknowledged for a certain period of time? Yeah. So because we are global, we really do our best if we don't have to to not involve someone who's not currently working. It's one of the benefits of having a global team is I work nine to five. My friends in Czech Republic work nine to five. In The Philippines, they work nine to five. Everyone kinda keeps their own hours. So our first priority is gonna be to get someone in a specific time zone to acknowledge, resolve, and alert. If it's been five or ten minutes and that there's been no response, we'll then escalate to a senior member in each of those regions. Again, we're trying to keep it in the right time zone, trying to keep the the noise down for everyone. If after fifteen minutes, we still don't have that response, we've involved some senior engineers, then it's gonna start routing to other time zones. So because of how we have our escalation policy set up, originally, we just wanna go this business hour, but we then also have the option to bring in other teams. If it's been an hour, I think still nobody's responded, which we've never seen happen. We do have, like, our top level management listed there, so not as a threat. But, you know, just in case, like, Big Boss will get called in if nobody else has acknowledged these incidents. We I haven't seen one go past the fifteen minute mark. People are pretty quick just because of how, like, easy it is to get the alerts on your phone and in Teams. But this has been, you know, pretty easy for us to manage that way. Yeah. No. That's great. Thanks for taking us through your escalation matrix. I do wanna give a quick call out here. What I love is that your team have been able to sort of rip and replace, the call capabilities that you were using Opsgenie for, which was, you know, you know, schedules, your on call your on call escalations, get alerting. I also wanna call out the fact that you guys have you you you use mobile app for your notifications. You also have your chat ops tools, which we will talk about in a minute setup. You know, you also do you guys get phone calls and text as well as part of your We have text as, at that ten or fifteen minute mark, we'll send everyone a text. I think the phone calls we leave up to the individual engineers. So we always have, like, a personal notification rule set. So if someone prefers phone calls, they can set it up there. We don't mandate it, just because whenever we were first setting up, we were saying, like, we had things configured wrong, so we were getting phone calls all over the place. But it's we kinda leave that one up to people. We will send the text. The push notifications on the app are really easy to view. It's the same info that you can see on the alert here. So that's been great. Yeah. And that's the thing. Right? Like, you have flexibility to set up notifications the way you want to. You know? You don't all have to be notified the same way, and that's another cool thing that you can do with, you know, solo windows and response. And you sort of set up routing rules for emails coming into your internal mailbox. How have you done that? Can you, like, give us a walk through of that? Yeah. So we have, like most ops teams, we have service accounts. Sometimes there's not a way around that. But for security reasons, we don't have, inboxes set up for those service accounts. We have emails that have the account set up and let people log in, but you don't actually receive any of the emails in that inbox. So in order to still kind of get the, notifications that you might have, you know, hey. This token's gonna expire or here's this action required, we have a distribution list that's kind of shared by those emails and anything that would go to that service account instead goes to a distribution list. That then routes to all of our team, so we basically get any emails coming to these service accounts to our team, which is great until some marketing spam gets a hold of that email, and you start getting, you know, this week in whatever, like, newsletter. So it became this tribal knowledge of what you needed to set up in your Outlook in order to filter out some of that spam. And then once you even got the valid alerts, you have to either take action yourself or hope somebody else has taken action. There's no way to know this person's gonna do something or this ticket was created out of this. So it was just it wasn't the right way for us to handle that. So how we've improved on that is we actually route now. We have this internal again, it's still just a distribution list, that forwards to a global, SolarWinds incident response email. We based on, either the subject or, you know, who the email's from, what's in the body, we can then route this in SolarWinds instant response to services that we have set up. We now handle all of the suppression, all of the, silencing of some of that unneeded spam directly in a shared platform platform instead of requiring everyone to have this set up in their Outlook rule sets. This has been way easier for us. We also get the added benefit of acknowledgment of those emails. We get an alert from an email and I acknowledge it. Nobody has to wonder, has someone seen this? Is someone doing something? There's a shared place that we can all view what's going on with it. We also use this for, like, our engineering teams to submit alerts to us. Hopefully, we never get to a point where we need that. Right? The goal is to get them automated, but we do have this as a fallback in case they need to kinda reach us quickly. Yeah. But I can see that you have, different services mapped to the rules. So I can see that you have GitHub. You have AWS. Could you could you, like, give us, like, a walk through of how you just set up the rules? Yeah. Absolutely. So, I'll use this one as an example. So whenever you look at the actual rule, it'll give you kind of a preview of the last thing that came in. So here, what we're doing is we're actually looking at the from field of the payload, and we're just using some regular expressions to see if it has that at github.com. All of those GitHub emails, for the most part, are going to route to our GitHub service. So that was a really easy way for us to set that one up. We do get, like, some AWS emails. So we we look, you know, for security hub in the body on that. If we have a pay or an email with Artifactory in the subject line, it's pretty easy to figure out that one needs to route to, like, our clean city environment. So that's that's sort of how some of this routing works is we're just looking at different fields in those emails, and then based on what it is, we can just set up our suppression rules on that specific service. Yeah. Just I'm going to do two quick call outs here. One is, we the the platform, solo events, instant response integrates with over 200 plus tools. So we we we receive alerts from SolarWinds over the over the team for sure, but we also receive alerts from Prometheus, Grafana, AWS, GCP. You know, whatever you even from ServiceNow, you could we received tickets. We received tickets from, SolarWinds service desk as well. So the platform is really well built out for ops teams. I also wanna give a quick call out. Right now, you will see this podcast branding everywhere. But in the next couple of months, SoloWind SquadCast is going to sit out of the SoloWinds, suite of, products. We're in a massive platform unification effort. So just because if you're confused, like, why doesn't this look orange, the following orange, and why is, like, the font completely different? We're looking to for sure. Yeah. We're undertaking massive, unification efforts. And then once we do that, you will have, everything you will you will truly have unified visibility with observability, incident response, ITSM, everything sitting under one speaker, product. So that's gonna look amazing. Yeah. Okay. And like like, as Sanchez mentioned, even the, you know, observability from SolarWinds, we have all of those alert sources set up as these global event rule sets. I'm using emails to demonstrate here because it's pretty easy to look at. But we have our, observability cloud and self hosted, any log monitoring. All of those go to global event rule sets so that we don't have to set them up individually per service. It's just one single place where you can integrate those sources. Yeah. Could you walk us through what does your response flow look like today? Yeah. Absolutely. So I have a demo alert here that I'll share. So I'd created this earlier beforehand just so that I could kinda showcase this, functionality. So I have this, we have a Teams channel set up that all of my team are members in, and so you'll see this, you know, demo ignore me is gonna be the same alert here. I've acknowledged this one just so that it doesn't continue to escalate throughout our our roles. So you'll see that it has here in the title acknowledge. It's got a little yellow thumbs up like someone's looking at it. But say, you know, I'm in my day to day flow, I'm in a meeting with Sanj, and I get this alert in a Team's channel. I'm already in Teams, so this is very easy. It's just switching to a different tab. Right? I'll come in here and go, hey. I'm looking at this one. Right? Submit that note. I haven't really done much here. I'm just kind of letting someone know if they happen to see it that it's there. Any other person that is in this Teams channel can see, hey. I'm looking at this one. But say you don't necessarily use Teams for, SquadCast or for SolarWinds and Star Response. Say you like to use the web UI. All of this info is also going to be reflected in the UI. You'll see it actually routes to my specific user just based on that, shared email, and this works both ways. So if I, want to, go here and say, hey. I'm on the UI, I can do that as well and this will pop back up right here on, the Teams channel. I'm gonna resolve this one because it's it's all finished. I'll say, my resolution reason is I'm done demoing. Resolve that. The info that you need to work these is here. We routed this to a service that's just alerts from our customers, but this might say TeamCity. This might say Artifactory, GitHub. You know exactly what's affected. Any description on the incident is gonna show you right here. You can click directly to the incident on the link if you do wanna jump to the UI. It's, again, all the information that you need right there. But for our use case, we haven't had a need to, outside of configuration, really use the UI. We've been working out of Teams because it works very well. And you can even use, like, some Teams features, like, mention someone right here because it's just a thread. Yeah? So now that I've resolved that one on Teams, you'll see here, again, everything's reflected. It shows resolved. My last little note there is, included. So all of the functionality that you can do here in the portal, we've also been able to accomplish in that Teams channel. Yeah. That looks great. I also want to, say that we have a similar integration with Slack. So if any of you have Slack as your, you know, your response or your chat ops tools, you can set up a similar workflow within Slack as well. We're not just, we're not agnostic of any, like, chat chat ops platform. Also, just a quick call out here. So if you if you were to look at the at the bottom right, you will see the entire activity timeline emerge. So all the actions that Chase has taken, they are being mapped out in something we call an activity timeline. And the activity timeline is also you can also download it. The reason I'm calling out this is because we spoke about retrospectives earlier, and, the activity timeline does give you an entire structured overview into what actions were taken. And you can also download it. And then when you are setting up a post mortem, which you can do it in the parts in the in the product, you can just see what happened when, and that can help you, in the process of continuous learning. Okay. Moving on. So, Chase, we we spoke about the fact that you had an alert noise problem before, and you have been able to, you know, work on that and sort of improve that with suppression rules within the, SolarWinds incident response platform. Yeah. So we, one of our, like, constants is trying to do retrospectives and keep up with, you know, what has happened, why did it happen, how do we prevent it from happening again. I think it's a really good practice when you're using alerting tools and supporting these platforms is to learn from failures and make sure that you're aware of the failures. All as a comparison here, I have our resolved incidents for the last seven days. This is what we as a team use, on a weekly basis. This takes us maybe five to ten minutes in our stand ups on Mondays, to kinda review, hey. Here's all of the incidents that we got last week. Compared to our suppressed incidents where we have 61 of them, them. And this is some of the emails that we get that we don't necessarily see, or want to see. These are, you know, just informational things. They don't need our action, but it's nice to be able to go and reference them here if you, you know, for some reason, were interested in what you got in the last seven days. But this resolved this I mean, we cut down from 24 or I'm sorry, from, 85 incidents to 24 incidents that we can now scroll through. And you'll see some of these have been merged together. We have some intelligent grouping that can happen as well if you get a lot of duplicate incidents coming at once. All of that's helping us cut down on that noise. So now, on a Monday, we can sit there five, ten minutes and just say, hey, Chase. What happened with this one? Well, I was demoing SquadCast for a webcast. And very quickly, no. This is most likely a valid alert because it actually made it to our resolved queue instead of just being something that was passed to the suppressed queue. So, Chase, what I love about this is that, you know, your team has and replaced Opsgenie as core functionality, which was on call scheduling and alerting and escalations. But you've also sort of extended the capabilities beyond that. You've actually built out instant response processes. The fact that your team meets every Monday every Monday. Right? Yes. Every Monday. Yeah. And you sort of go over, the suppressed incident. I think not just use the feature, but you've really built a process around it, which is fantastic to see. I know that you've also set up a Service Graph, because, you you had a noise you had a problem with a lot of noise. And, could you just show what does that look like today? Yeah. Yeah. So one of the things that we love about service graph is if, for some reason, you have, you know, a massive influx of alerts all come at once, you have 10 different services affected, they're all dependent on each other, and you don't know where the issue is, we have dependencies between services mapped out. It's pretty easy to do just like filling in a field of what service does this depend on. So now, say you pop in here and you have alerts on, these Artifactory services, install anywhere and AWS, all at the same time. If this is the graph right here and you're seeing these all have alerts and this also has alerts, there's a pretty good chance that this AWS service is going to be the cause of these having alerts. You can kinda follow this flowchart down. But, say, you have, you know, maybe these two having alerts but there isn't an issue on AWS, this is probably the best way to start. So we tend to just work down this graph depending on, like, you know, the lowest affected service and start from there. So identifying that root cause has become a lot easier for us. Oh, that's fantastic. And, you know, we we spoke about intelligence earlier with regard to suppression and, you know, your duplication and correlation. But I think, intelligence can also come with service visibility and the way we're we we're visualizing services. And I think the way that your team has set up set this up in, within Swallow's instant response is, like, a great example of that. So yeah. I'm also going to say that, you know, intelligence or automation and AI is is an integral part of the SolarWinds platform. You know, it's not just something that we have slapped on. It's truly built with with the platform. We have a couple of, ML based monitoring capabilities, which we have not covered in this demo, but we'll talk about it in subsequent, demos that we do. We also have, you know, suggested runbooks that can help you respond faster. A big part of, what we do is also better stakeholder comms. If you are a class user, you must be using the status pages, as well and quickly your comms. We also offer sort of an instant response also offers both public and private status pages that you can look into if you are thinking about the migration. There's also a very robust analytics and reporting for robotic features that we have set up within the platform. Chase, thank you so much. I love the fact that your team has been able to, you know, replace Opsgenie with SolarWinds Instant Response. And the fact that you've actually really extended your capabilities with Instant Response is what makes me super happy and super excited. I really want to see what your team does with the rest of the functionality within the platform in the next couple of months. And I hope we're talking about that. You know? Yeah. Yeah. Looking forward to it. Yes. Yeah. In the upcoming webcast. Okay. Moving on, we're going to talk a little bit about the big m migration. We know that Opsgenie has been an integral part of your system for a very, very long time. But I just want to say that, you know, we at Swindler Wind is a response. We have done the migration ourselves. We have helped multiple customers do it. We have even had our internal teams do it, you know, so we can 100% help you do it as well. Now when you think about migration, we look at it in two ways. One is you can do a self serve migration. We have a public rep for the migrator, so I'm I'm just gonna link that in the chat below. The migrator can take care of, you know, migrating users, teams, services, escalation policies, and schedules from Opsgenie to Sullivan's instant response or IR. I will say, though, we're looking to evolve this migrator, as and when we get some customer feedback. So if you choose to move to SolarWinds instant response and if you if you choose to migrate, then we're happy to incorporate any feedback that you may have. We also have something called guided migration support or white glove migration, and we think about this in different steps. So the first step is, you know, we lock in the legal requirements between sales and and your team. Once the contract is locked in, we're going to assess your requirements. We'll also do a phase wise, migration depending on how many teams you have, you know, how many users are there in each team. We're going to review your current use case. We will review how Opsgenie has been set up. We're going to see how different features have been set up within Opsgenie. And then we'll also sort of try to understand what are your specific requirements for from solar with instant response. We will help you, configure any third party integration. So if you integrate with ServiceNow, we can help you do that. We have a bidirectional integration with ServiceNow as well as Jira. And then once you're all set, you go live. And while you go live, I do want to call out that we do, trainings with different teams as well. If your team if your teams need to be, you know, they need to get more familiar with the with the product. We also do something, which we call, a post onboarding q and a in case your team does not need a full full fledged training. Chase, any thoughts here? I know you've done this migration yourself. Any parting thoughts on this? Yeah. I guess just reassurance. We migrated before there was even, like, a migrator available. So we did this guided migration support. Migrations are scary normally from software to software. Reassurance to this one is not. We had a great solutions engineer. We sat down with him for, I think, thirty minutes, and he sort of explained this feature in Opsgenie is this feature in incident response. This feature is this feature. After we sat and had that call, we poked around on the platform and we were already working on things within that first day. It's very easy to learn. It's very, like, the just transferring over your existing schedules does not take very long at all. So don't think it's like this really, really big deal or it's gonna take forever. It was super easy for us to get set up. Thank you so much, Chase. I will say if you want to talk with any of our experts, about migrating to SolarWinds instrument response from Opsgenie, you can take the poll here, and one of one of somebody from our sales team is going to reach out to you. So I think that wraps it up for today. Thank you so much for being here for joining us today. Thank you, Chase, for being that as an expert. I will say this again. You know? Please don't be scared with this migration. We can totally help you help you help you and your team. And if you want if you want to hear more from us about anything specific with regard to this migration, please write to us in the chat, get back to us later, whatever so whatever floats your board. Thank you so much. Thanks, everyone.