Group alerts with monitor dependencies

When a shared component fails, such as a database or a load balancer, every service behind it fails too. Dependencies let you tell Uptime Tracker about that relationship, so you get one page for the root cause instead of a storm of alerts. Dependencies are a Team plan feature.

How it works

• While a parent monitor is down, the down alert of a monitor that depends on it is held.
• If the dependent monitor recovers while its parent is still down, its alert and recovery are never sent. The incident timeline records that paging was suppressed.
• If the parent recovers first and the dependent monitor is still down, its held alert is sent then, because it is a separate problem.
• Checks keep running and incidents are still opened and recorded for every monitor. Only the paging is held.

The link between two outages is treated as a hint, not proof of cause: the timeline names the parent that was down at the time.

Set up a dependency

1. Go to Monitors and open the monitor that relies on something else.
2. Scroll to the Depends on panel.
3. Under Parent monitors (up to 20), tick each monitor this one depends on.
4. Choose Save dependencies. To remove all dependencies, untick everything and save.

The same panel lists Monitors that depend on this one, so you can see the impact of a parent before you change it.

Example

Your Checkout API and Search API both need Postgres (a TCP monitor). Make Postgres a parent of both. If Postgres goes down, you are paged once for Postgres; the two API alerts are held, and if the APIs recover together with Postgres they are never sent.

Rules and limits

• Up to 20 parent monitors per monitor, all in the same workspace.
• A monitor cannot depend on itself, and a dependency that would create a cycle (A depends on B, B depends on A) is refused.
• Only people who can edit the monitor can change its dependencies.
• If the workspace leaves the Team plan, saved dependencies stay but alerts are no longer held.

Troubleshooting

• "That dependency would create a cycle": one of the parents already depends, directly or indirectly, on this monitor. Remove the reverse link first.
• I still got paged for a child monitor: the parent was not down yet when the child's outage was confirmed (for example, the parent's failure took longer to confirm), or the parent recovered while the child was still failing.