Dependency monitoring

When a shared service goes down, every service that relies on it fails too. Without context, that looks like five separate outages. Dependency monitoring labels each downstream failure as dependency unavailable, so the alerts and incidents point to the service that actually broke.

Available on Pro and Enterprise.

How it works

Add a Dependency URL to a monitor. On every check, Vantield checks the dependency first:

  1. Vantield sends a GET request to the dependency URL. It passes on a 200 response.
  2. If the dependency passes, the monitor's own URL is checked as normal.
  3. If the dependency fails, the monitor's own URL is not checked. The result is recorded as dependency unavailable, with the dependency's error attached.

Incidents record a root cause of either own (the service itself failed) or dependency (its dependency failed), so the incident history shows where each outage actually started. The dependency's status code and response time are stored with every check.

Example

Three services all rely on one authentication service:

auth.example.com/health        <- monitored on its own
api.example.com/v1/orders      dependency: auth.example.com/health
api.example.com/v1/billing     dependency: auth.example.com/health
app.example.com                dependency: auth.example.com/health

If authentication goes down, the auth monitor opens an incident with root cause own. The other three alert as dependency unavailable with root cause dependency, so whoever responds starts with the auth service instead of investigating three services that are not broken.

Choosing a dependency URL

  • Use a lightweight health endpoint that returns 200 when the dependency is usable.
  • Monitor the dependency itself as a separate monitor, so it has its own incident history and alerts.
  • Each monitor has one dependency URL. Point it at the dependency whose failure you most want separated from the service's own failures.

Next: Data retention