When one upstream system fails, several downstream checks often fail with it. Paging separately for the API, worker, admin UI, and status endpoint can turn one incident into a wall of duplicate notifications.
Model the relationship you already know
StackEye lets a team create parent-child dependencies between probes. When a parent probe is DOWN, downstream checks can be marked unreachable and their alerts suppressed. The incident still preserves the affected children, but the notification path stays focused on the upstream failure.
database check (parent) DOWN
|
+-- API check unreachable / suppressed
+-- worker check unreachable / suppressed
+-- admin check unreachable / suppressedThe dependency graph prevents cycles, and recovery re-evaluates the remaining parent relationships before restoring a child's alert behavior.
What suppression does—and does not—prove
A configured dependency is operational context supplied by your team. It is not automatic root-cause certainty. “Parent is down” is a defensible reason to suppress a child's page; it does not prove that no other fault exists.
That boundary keeps the feature useful. StackEye can reduce a known alert cascade while still preserving incident impact and history. It does not need to claim universal causal inference.
Good candidates for dependency modeling
- A public API that depends on a database or private service.
- Several regional endpoints behind one load balancer.
- Application checks that all depend on one identity provider.
- Multiple services running on a Station-managed host.
Start with a small number of relationships you can defend. If the graph becomes speculative, the suppression becomes harder to trust.
Join the StackEye beta waitlist to evaluate dependency-aware monitoring with your own stack.
← Back to Blog