We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You are failing over the primary database at 02:00 on a Saturday. The expected disk and connection churn will trip every health check on every dependent service. Without suppression, the entire on-call rotation across 6 teams gets woken up for a planned, expected, completely normal event.
This happens constantly. Cloudflare's internal playbook requires a maintenance window for any change that touches a production primary, no exceptions. In 2019 a large retailer suppressed an entire region during a planned change and missed a real incident on unrelated checkout, costing 45 minutes of lost sales. The lesson from that incident: suppression must be scoped to the specific service being maintained, never applied to a whole region or team.
Alert suppression silences alerts you already know about. Planned maintenance, known broken services during a deploy, and cascading symptom alerts from a parent failure. It stops noise that would otherwise distract from real problems.
Suppression is not a single feature. It splits into two distinct mechanisms that solve different problems.
| Type | Trigger | Scope | Risk |
|---|---|---|---|
| Maintenance window | Operator creates before a planned change | Time-bounded, service-scoped | Too-broad scope hides real incidents |
| Dependency suppression | Automated when a root cause alert fires | Graph-driven, child services only | Stale dependency graph misroutes |
Maintenance windows are manual, time-bounded, and scoped to the service being maintained. The operator creates the window before the change starts, and it auto-closes after the planned duration.
Dependency suppression is automatic. A service dependency graph tells the alerting engine which services depend on which. When the database goes down, downstream symptom alerts are suppressed automatically. Only the database team gets paged. Downstream teams see a read-only notification so they stay informed without being woken up.
BigPanda and Moogsoft built entire products around dependency suppression, which they call topological correlation. PagerDuty and Opsgenie offer lighter versions with manual dependency mapping.