Vendor health

When a vendor API that many products depend on starts failing, everyone using it sees failures at the same time. SutramX can see that pattern across its customers. When it does, it marks the vendor as degraded, adds "Likely external" to your incident and alert, and shows how the vendor's own status page compared.

This is independent of the vendor's status page: it comes from SutramX's own check results, not from reading what the vendor publishes. Vendor health is included on every plan, Free too.

What you see#

On an incident and its alert#

If your monitor's failure matches a degraded vendor, the incident's Why this alert panel gets a Third-party vendor finding and, when it is the likely cause, the Likely not your fault badge. The down alert reason gets a suffix, for example:

The incident timeline records "Likely external: Stripe API degraded".

The Vendor health view#

Open Third-party status in the sidebar (under Checks & insights). The Vendor health section at the top lists vendors with two columns side by side:

Each detection also shows how the official status compared, for example 14 min ahead of Stripe, Stripe reported it too, Not on Stripe's status page yet or Stripe never reported it. SutramX often sees a problem before a status page is updated, but not always: the comparison depends on how often the status page is polled and how quickly the vendor posts.

Below the table, Recent vendor issues (30 days) lists past detections as Ongoing or Resolved.

How detection works#

1. SutramX keeps a fixed catalogue of known vendor API hostnames: about 80 providers, including Stripe, OpenAI, AWS (by region), Razorpay and Supabase.
2. When checks against those hostnames fail with a timeout, a 5xx error, a connection failure or a TLS error, the failure counts towards that vendor. DNS failures, 4xx responses, rate limits (429) and bot-protection blocks don't count, because they usually belong to one customer's setup.
3. A vendor is flagged only when at least 3 different customer accounts are failing against it at the same time, and a meaningful share of the accounts checking it are failing. The signal has to hold for a short period before it is confirmed, so one blip doesn't flag a vendor.
4. The vendor is cleared once the failures fall away.

Detection only adds context. It never changes whether or when an incident opens, or whether an alert is sent.

Privacy#

• Only aggregate signals are used: whether a vendor is failing for several accounts, never which accounts.
• Only known vendor API hostnames are matched. Your own domain is never pooled, even if it points at a vendor through a CNAME.
• No customer's monitors, URLs, results or account details are ever shown to another customer, and exact counts are not shown. Wording is "several" or "many SutramX customers".

Vendor health and third-party status#

Vendor health is different from following a service's official status:

Following a vendor in Third-party status doesn't make it the likely cause of your incident; only a detection does.

Common questions#

Do I need to set anything up? No. If one of your monitors checks a catalogued vendor API hostname, detection applies automatically.

My vendor isn't detected. Why? Detection needs enough SutramX customers checking that vendor at the same time. A problem that only affects your account (for example an expired API key) is yours to see in your own monitor.

Does this replace monitoring my integration? No. Keep an API check on the calls that matter to you.