Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.tallwatch.com/llms.txt

Use this file to discover all available pages before exploring further.

When your database goes down, every service that depends on it fails too. Without dependencies, that’s a dozen incidents and a dozen alerts for one root cause. Dependencies let you mark the upstream monitor so the downstream alerts stay quiet while the real problem is already paging you.

​
How it works

On a monitor, set one or more other monitors as dependencies. When an incident opens for this monitor, Tallwatch checks its dependencies first. If any of them is currently down, the dispatch is suppressed: the incident is still recorded, but no alert goes out for it. The suppressed dispatch is written to the record as suppressed, so the incident is fully auditable later. You see that it happened and why, you just don’t get paged for it.
Dependencies gate alerting, not checking. The downstream monitor keeps running its checks and opening incidents. Only the notification is held back while an upstream monitor is down.

​
A typical setup

Say API healthcheck and Web app both depend on Primary database:
  • The database goes down. Its monitor opens an incident and pages you.
  • The API and web monitors fail too and open their own incidents. Because their dependency is down, those alerts are suppressed.
  • You fix the database. It recovers, and so do the services that depend on it.
You get one alert about the cause instead of three about the symptoms.

​
Choosing dependencies

Point a monitor at the things it genuinely can’t work without: the database, the auth service, the upstream API. Don’t chain dependencies speculatively. The goal is to silence symptom alerts during a shared outage, so only the relationships that actually cause correlated failures are worth encoding.