The Noise Problem Every Network Team Knows
It's 2:00 AM. A core router goes down. Within seconds, your alerting system fires — every downstream interface, every BGP neighbor, every dependent route generates its own alert.
This isn't a misconfiguration. It's how alerts evaluate entities independently, with no awareness of upstream failures. This pattern—cascading alert storms from a single failure—is one of the most common causes of alert fatigue in network operations.
In 2026.2, we're addressing this with Condition-Based Alert Suppression — a platform-level capability available across the Observability Self-Hosted.
What Is Alert Suppression Condition?
Alert Engine for Suppression Condition introduces a "suppressed" state — an alert can be triggered and active yet skip its actions when a defined suppression condition is met.
Think of it as a third condition in your alert lifecycle:
Condition | What It Asks |
|---|
Trigger | Should this alert be active? |
Suppression | Even though active, should actions be skipped? |
Reset | Should this alert be cleared? |
Key point: 'Suppressed' is a state modifier, not a state. An alert is always either triggered or reset. Suppression controls what the engine does while active — the alert remains visible, logged, and reportable throughout.
Don't confuse this with Alert Muting (maintenance job type), which blocks all alerts on an entity during a time window. Suppression Condition is per-alert and condition-driven — a fundamentally different capability.
How It Works
The engine evaluates trigger and suppression conditions independently on each cycle. When both are true simultaneously — alert is active, actions are skipped. When suppression clears while trigger remains true — actions fire immediately, just as they would after a reset-retrigger.
In the Alert Wizard, a new Suppression Condition tab sits between Trigger and Reset. It defaults to off — all existing alerts behave exactly as before on upgrade.
When enabled, you define the suppress condition and a Suppression Message — shown in place of the Trigger Message while suppression is active, giving your team immediate context on why the alert is silent.
⚠️ Critical: Use the same "I want to alert on" entity type for both Trigger and Suppression conditions. A mismatch won't error — it will silently misbehave.
What Suppression Blocks — And What It Preserves
Blocked during suppression:
- Initial and repeated trigger actions
- Escalation progression — level freezes at current level, resets to Level 1 when suppression lifts
- Reset actions if the alert clears while still suppressed
Always preserved:
- Alert visibility on All Active Alerts
- Complete audit trail — history log shows "Skipped" entries for skipped actions
- Reportability — "Suppressed" is a real DB property, fully queryable
- API access via SWIS SDK
Finding Suppressed Alerts in the UI
Suppressed alerts appear on the All Active Alerts page with a "suppressed" label and display the suppression message in place of the Trigger Message. A "Hide suppressed alerts" toggle in the More dropdown lets NOC operators clear them from the working view without losing the record.
Note: The new All Active Alerts modern dashboard does not yet support the hide/filter for suppressed alerts. The legacy All Alerts view has full support. This will be updated in a future release .
The OOTB "All Active Alerts" report has also been updated to include the Suppressed property — useful for auditing suppression patterns over time.
Current Limitations
- No OOTB alerts ship with suppression pre-configured
- Global Alerts ("N or more objects meet condition") cannot use suppression
- Event-based conditions excluded from suppression builder — by design, as they never evaluate to false
- Delayed trigger conditions: suppression cannot engage before the trigger delay elapses
Summary
The alert suppression condition provides the SolarWinds alerting engine with context awareness that it previously lacked. Your alerts still fire. Your history is complete. Your audit trail is intact. You're just telling the engine the following: "I know about this — don't wake anyone up unless the situation changes."
