Skip to content
Knowledge base

How to monitor an API your business depends on (vendor watch)

Watch Stripe, GitHub, AWS, or any of the tracked services in the outage catalog, and get alerted through your own channels the moment RealUptime's probes confirm an outage, not when a crowd starts complaining.

1. Understand what vendor watch actually is

Vendor watch turns measurements RealUptime is already taking, from the public outage catalog, into a dashboard tile and an alert on your own account. It never opens an incident on your own status page and never speaks for a vendor: what you see is RealUptime's own probe reading for that vendor, shown beside the vendor's own status-page claim when we have one, and the two are never merged into a single number.

2. Know the current pricing and cap

Vendor watch is a flat-rate add-on, $11.99/mo or $119.90/yr, on top of any paid Monitor plan (Growth or Scale); the Free tier has no way to buy it, since the add-on rides on a paid Monitor subscription rather than replacing one. Once held, the add-on covers up to 100 watched vendors on the account. That 100 is stated plainly as an internal fairness cap on probe capacity, not a per-vendor charge: the price is flat either way, whether you watch one vendor or the full cap.

3. Open the vendors section and add one

In the Monitor dashboard, find the Vendors section. Growth and Scale accounts without the add-on see an upsell explaining the flat price and the fairness cap, with a link to billing; the free tier sees the same upsell rather than a truncated catalog, since the underlying measurements are the same either way. With the add-on held, search the outage catalog by name (Stripe, GitHub, AWS, and the rest of the tracked services) and add each one your product depends on. Each tile shows how many regions that vendor is checked from and how recently.

4. Know exactly what triggers an alert

Only a probe-confirmed measured event opens, reopens, or closes an alert: our own probes recording the vendor's outage event starting, resuming after a false recovery, or ending. A rise in user reports, a spike in social-media chatter, or the vendor's own status page claiming a problem never opens a vendor-watch alert by itself, even though any of those three can appear as a labeled, separate fact on the tile. This is the same never-falsify rule the rest of RealUptime Outages holds to: alerts fire on what we measured, not on what anyone said.

5. Choose where the alert goes, and generate evidence after the fact

Vendor-watch alerts route through the exact same alert rule as your own monitors: email, Slack, a registered webhook endpoint, or any channel in the notification registry (Discord, Microsoft Teams, Opsgenie, Zapier, and the rest). There is no separate alerting setup to configure. Each watched vendor's tile also links to Generate SLA evidence report, the same probe-measured evidence report a visitor can request from that vendor's own public outage page, useful for a support ticket or a credit claim with the vendor itself.

Go deeper

The full reference lives in the docs: Monitor documentation. Error codes named above are each explained in the error-code reference.