Transcript
2026.2 is the addition of an alert suppression condition as part of alert management. Alert suppression is part of our continued efforts to combat alert noise. You're designed to work with specific alerts, not global alerts, with a user-defined set of parameters. Suppressed alerts are still created and stored with suppressed status ensuring full auditability in active alerts, out-of-the-box reports, and through the Swiss SDK. But actions and escalations are skipped. Let's dive in. Here we're starting out on our Manage Alerts screen, which should be very familiar to you if you've managed any alert actions in the past in our platform. We're going to add a new alert. Since this is just a test, I'm going to go ahead and set it up that way. You'd start building your alert the same as any other alert that you're building, except for now you can see there's a new tab up here for suppression condition. As I mentioned, alert suppression is not really designed to help you with your global alerts. If you're looking for help with global alerts, look for things like anomaly-based alerts, or groups and dependencies, or some other method like custom properties in order to help you reduce the noise in those states. This is more for specific scenarios like a bunch of devices sitting behind an edge router. If the edge router goes down, you don't want to receive a bunch of notifications. In that case, the edge router going down would be our suppression condition. Everything else would be under our alert condition. We can select something here like if we're looking for, maybe this is location-based, then we can say everything that is in this remote office of Plano is we're wanting to know if it is down. So we're going to pull up status is equal to down. If it is in this remote office and the status is down, then we want to receive an alert. Then if we go to our suppression condition, by default, no suppression condition is designed, but we can define a suppression condition and our dynamic builder is going to be looking very similar to our trigger condition or a reset condition. Just like with the reset condition, you can copy the condition from the trigger. So if you want to save yourself some extra steps, it'll copy what you already have in there, or it will start with a new dynamic builder just as we saw previously. In this case, we would make our suppression condition for a node being down, which in this case will be node name. Then we would say it's a specific node. We'll just pick on something because this doesn't matter, it's just a test. Let's say this was our edge router and then everything behind it would now be suppressed if that specific edge router is down. We wouldn't receive the escalations or the trigger actions, but the alert would still be active, thus preserving the integrity of knowing that those devices were down at the time, but preventing the amount of alert noise where we're getting a bunch of notifications that we don't need to receive. So that's just a quick look at alert suppression. You can test it out in your environment today by upgrading to SolarWinds Platform 2026.2.
