Third-party dependency monitoring

Who this is for

Teams whose product depends on external APIs, SaaS webhooks, auth providers or cloud endpoints - and who currently learn about vendor degradation from users, not from monitoring.

What it covers

API dependency monitoring, SaaS dependency monitoring, external API monitoring and dependency performance monitoring are the same practice at different scopes: request the endpoint like your product does, record what happened, and compare across regions before alerting.

How checks run

• Scheduled, not sampled on demand: one task per dependency per region per interval, via broker to workers.
• Separate origins: each region resolves and connects independently; every result carries its region.
• Quorum verdicts: multi-region failures inside a short window declare an incident; consecutive successes clear it.
• Validated targets: SSRF policy rejects private/loopback/link-local/metadata addresses - recorded as policy blocks, never as vendor outages.
• Explicit states: target problems, infrastructure problems and transitional states are distinct, because they have different owners.

What a missed probe means

If the scheduler, broker or a worker is unavailable, checks do not run - and the system reports that. A missed probe is never backfilled with a synthesised result. An observation that did not happen must never appear in a history you intend to rely on.

Plan limits (enforced server-side)

• Free: 3 dependencies · 1-minute checks · 24-hour retention · email alerts.
• Pro: 50 dependencies · 15-second checks · 90-day retention · Slack + API + attribution + evidence.
• Enterprise: custom scale, client isolation, white-label reporting.

What to do next

Follow the quickstart, browse live vendor posture, or see how observations become attributed incidents.