Monitor Dependencies Explained: Stop Alert Storms

Imagine your production database server goes down at 2 AM. Within 60 seconds, you receive:

• Alert: API server is down
• Alert: Background worker is down
• Alert: Admin dashboard is down
• Alert: Webhook processor is down
• Alert: Scheduled report runner is down
• Alert: Database is down

Your phone is lighting up. You have six alerts but one root cause. Before you can even start investigating, you're triaging noise.

Monitor dependencies solve this. By telling PingBase that your API, worker, and admin dashboard all depend on the database monitor, it knows to suppress the downstream alerts when the root cause (the database) is already firing. You get one alert: "Database is down." You fix it, everything comes back up, and you get one resolution notification.

---

What is an alert storm?

An alert storm is what happens when a single root-cause failure cascades into many simultaneous alerts. It's one of the biggest problems with naive uptime monitoring setups at scale.

Alert storms are harmful in two ways:

1. They delay response. When your on-call engineer receives 15 simultaneous alerts, they spend the first 5 minutes figuring out that it's actually one incident — time that should have been spent fixing the problem.
2. They train teams to ignore alerts. If every major incident generates 10-15 alerts, on-call engineers start discounting individual alerts as "probably just another cascade." The signal-to-noise ratio drops. Eventually critical alerts get missed.

The solution isn't fewer monitors — it's smarter correlation. Monitor dependencies let you keep complete coverage while eliminating the noise.

---

How monitor dependencies work in PingBase

Each monitor in PingBase can declare one or more parent monitors. When a monitor fails and one of its parents is also currently failing, PingBase suppresses the alert for the child — because the parent is already alerting and is the likely root cause.

The logic:

Dependencies are directional: child monitors have parent monitors. A child can have multiple parents (suppress if any parent is down). A parent can have many children (all suppress when the parent is down).

Crucially, child monitors still run their checks — they're still monitoring and recording data. The dependency only affects alerting, not monitoring. When the parent comes back up and children are still failing (meaning the problem wasn't just the parent), their alerts will fire independently.

---

Common dependency patterns

Database as shared infrastructure

The most common pattern: everything depends on the database.

Result: database goes down → one alert fires (database). API, worker, admin, and webhook alerts are suppressed. Database comes back up → everything recovers. You handled one alert, not five.

Multi-tier application

For a tiered architecture where the API depends on the database, and the frontend depends on the API:

• Frontend → depends on API
• API → depends on Database

If the database goes down, the API fails (suppressed — parent is down), and the frontend fails (suppressed — its parent API is down, which in turn has its parent database down). One alert: database down.

Shared cache

If your application fails hard when Redis is unavailable (no graceful degradation), add Redis as a parent for your API and worker monitors. This is especially common for session stores — if Redis is down, every authenticated request fails, so your API monitor will also fail.

CDN and origin

If you monitor both a CDN URL (cdn.yourapp.com) and the origin server it pulls from, make the CDN monitor a child of the origin monitor. If the origin goes down, the CDN will eventually return stale or errors too — and you only want one alert.

---

Setting up dependencies in PingBase

1. Open any monitor's settings page
2. Scroll to the Dependencies section
3. Click Add parent monitor and select from your existing monitors
4. Save — the dependency takes effect immediately

You can visualize your dependency tree from the monitor list. Monitors with dependencies show a small indicator; clicking it shows the full parent/child relationship.

---

What about the status page?

Dependencies affect alerting, but status pages show the full picture. When your database is down and your API is also failing, both appear as degraded on your status page — because your users are experiencing both failures, regardless of the root cause.

This is the right behavior. Your status page communicates to users what they're experiencing. Your alert channels communicate to your team what to fix. Different audiences, different information needs.

---

Dependencies vs monitor groups

Monitor groups (folders) organize your monitors visually. Dependencies define alerting relationships. They're complementary:

• Use groups to organize your dashboard: "Production," "Staging," "Infrastructure," "APIs"
• Use dependencies to suppress cascade alerts: API depends on DB, frontend depends on API

You can — and should — use both. A well-organized monitoring setup has monitors in logical groups and dependency relationships that reflect your actual infrastructure topology.