Monitor Dependencies Explained: Stop Alert Storms

Alert storms are a symptom of a configuration problem. When you get 20 alerts at once, they all say the same thing: something upstream failed. The problem is your monitoring system doesn't know what's upstream from what — so it treats every monitor as independent.

Monitor dependencies fix this. You declare that Monitor B depends on Monitor A. If Monitor A goes down, any failures on Monitor B are suppressed — because you already know why B is failing. You get one alert for A, not one for A plus one for every service in the blast radius.

---

The anatomy of an alert storm

Here's a typical scenario without dependencies configured:

1. Your PostgreSQL database goes down at 2:47 AM
2. Your API starts returning 500s because it can't reach the database
3. Your background job runner fails because it can't read from the jobs table
4. Your admin dashboard returns errors because it queries the database directly
5. Your status page checker reports all user-facing endpoints as down

Without dependencies: five alerts fire simultaneously. Your phone wakes you up five times. You spend the first two minutes figuring out which one is the root cause.

With dependencies: one alert fires — the database monitor. Everything else is suppressed because it's downstream. You know immediately what to fix.

---

How monitor dependencies work in PingBase

In PingBase, every monitor can have a parent monitor. When a monitor is configured with a parent:

• If the parent is currently down, the child monitor's failures generate no alerts
• The child is still checked on its normal interval — failures are recorded in the timeline
• When the parent recovers, the child resumes alerting normally
• The status page shows the child as affected by the parent's incident

This means you always have full visibility into what failed — you just don't get paged for the downstream effects.

---

Setting up dependencies in PingBase

1. Open any monitor's settings page
2. Scroll to the Dependencies section
3. Set the Parent monitor — the monitor that must be healthy for this one to function
4. Save

That's it. PingBase handles the suppression logic automatically. You can chain dependencies — if A is the parent of B, and B is the parent of C, then when A fails, both B and C are suppressed.

---

Common dependency patterns

Database as parent of all application monitors

The most common setup. Your database monitor is the parent for every application service that reads from or writes to it. Database down → suppress all app-level alerts.

Load balancer as parent of backend instances

If you're monitoring individual backend instances and the load balancer goes down, all instances become unreachable. Set the load balancer as the parent — a load balancer outage suppresses instance-level alerts.

Auth service as parent of protected endpoints

If your auth service is down, every authenticated endpoint will fail with 401s or 503s. Set your auth monitor as the parent for any endpoint that requires authentication.

Primary region as parent of multi-region monitors

If you run active-passive failover and your primary region goes down, monitors in that region will all fail simultaneously. Setting a primary region health check as the parent suppresses the individual endpoint alerts during a full regional failure.

---

What still gets alerted

Dependencies suppress alerts, not data. You always get:

• An alert when the root-cause (parent) monitor goes down
• Full incident history for every monitor — including suppressed ones
• Status page updates showing which monitors were affected
• Recovery alerts when everything comes back up

What you don't get: a page for each downstream service that failed because of the parent. That's the noise you're eliminating.

---

How many dependencies is too many?

There's no hard limit, but keep the tree shallow. If everything depends on one monitor and that monitor has a misconfigured check, you might suppress alerts you actually need. A good rule of thumb:

• Maximum 2-3 levels of nesting
• Only create a dependency when the relationship is structural — not just correlated
• Test your dependency logic: take a parent monitor down and verify the children suppress correctly

---

The difference between suppressed and paused

Monitor dependencies suppress alerts automatically based on parent state. This is different from manually pausing a monitor (which stops checks entirely). With dependencies:

• Checks continue running — failures are recorded but not alerted
• Suppression is automatic and reversible — no manual action required
• You still see the full picture in your dashboard

Use pause for planned maintenance. Use dependencies for structural relationships between monitors.