A vendor’s status page is a web page. It answers HTTP 200 when the service behind it is healthy, and it answers HTTP 200 when that service is completely broken, because the page’s job is to load and tell you so. Point a plain uptime check at it and you have built something that alerts you when the vendor’s marketing site falls over. Nothing else.
What Your Check Is Actually Asking
Most third-party API monitoring goes wrong at this exact step, and it goes wrong silently, which is the worst combination. The check is green for months. Then Stripe has a bad afternoon, your checkout starts failing, and the dependency you carefully set up never said a word.
The fix is not a better tool. It’s being precise about which of three questions you want answered:
| What you check | What it tells you | What it misses |
|---|---|---|
| Vendor status page URL | The page is reachable | Everything, unless you assert on the content |
| Status page content or feed | What the vendor has publicly admitted | Anything they haven’t posted yet |
| A real API or health endpoint | Whether it responds right now | Failures behind auth, quota, or your specific account |
None of these is the right answer on its own. The third is closest to truth and the hardest to do politely against someone else’s production API. The second is what most teams should start with, and it only works if the check reads the page rather than merely fetching it.
The Assertion Is the Check
A status page fetch becomes useful the moment you stop accepting 200 as the verdict and start requiring the page to say the thing you expect.
In FlareWarden a dependency monitor takes an endpoint and an optional content assertion, using the same matching as content monitors: require specific text, or alert when specific text appears. The second form is what you want here. Not Contains on the words a vendor uses for trouble turns their own page into a signal, so a page that starts saying “degraded performance” fails your check while it’s still returning a cheerful 200.
Pick the string from the vendor’s own vocabulary, not yours. Providers are consistent about the words they use for incident states, and a five-minute look at their status page during a quiet week tells you exactly what to match. Feeds work too, and for some providers they’re better structured than the page: AWS publishes per-service RSS, and an RSS endpoint that gains an entry is easier to reason about than HTML that changed shape.
For common providers this is pre-solved. Forty services in FlareWarden ship as dedicated integrations that configure the correct endpoint, the expected response format, and the check parameters, so you aren’t reverse-engineering Shopify’s status markup on a Tuesday night. Smart Setup also finds these on its own, running domain-level detection for CDN, DNS, mail and hosting alongside a pass over your pages for payment processors, analytics and CMS platforms, then scoring each by confidence before you confirm anything.
Decide What Someone Else’s Outage Does to Your Status
This is the part teams skip, and it produces the most damaging version of the problem: a monitoring setup that cries wolf about other people’s infrastructure until nobody reads it.
A dependency failure should not automatically mean your site is down, because usually it isn’t. Your marketing pages render fine when your analytics vendor is broken. Your app is genuinely broken when your payment processor is. Those two deserve different verdicts, and FlareWarden makes you choose: Critical marks the parent monitor DOWN, while Degraded marks it DEGRADED and leaves the distinction intact on your own dashboard and status page.
Our recommendation is to be stingy with Critical. Payments, authentication, and your primary database or API host qualify. Analytics, session recording, support widgets, font hosts, and every A/B testing tool do not, however much the vendor’s own docs insist they’re mission-critical. If a customer can still complete the thing they came to do, the correct word is Degraded.
Marking who owns each dependency pays off later. FlareWarden asks whether a dependency is yours or a third party’s, and that flag is what turns a messy incident review into a short one, because “was this us” is the first question anyone asks. The strategic case for tracking any of this is covered separately in why third-party services are your site’s hidden weakness; this article is about wiring it up so the answer arrives.
What Deserves a Dependency Monitor
Not everything your site loads. A modern page pulls in dozens of external things, and watching all of them recreates noise in a new place.
Four categories are worth it, in rough order of value:
- Anything in the money path. Payment processors, tax and address validation, fraud scoring. If it’s between the customer and a completed order, watch it.
- Anything in the login path. Identity providers, SSO, email delivery for magic links and password resets. An auth outage looks exactly like a total outage to the person affected.
- Infrastructure you don’t run. CDN, DNS, object storage, your hosting provider’s own status. These fail rarely and spectacularly.
- The one API your product is a wrapper around. Most small SaaS products have one. You know which it is.
Skip the rest, or set them to Degraded and stop thinking about them. The free plan’s 15 monitors go further than people expect once you’ve stopped instrumenting your font provider.
The Limits Worth Saying Out Loud
Two of them, and neither has a clean fix.
Vendor status pages lag. They are written by humans during an incident, usually after support volume has already spiked, and sometimes after your customers noticed. A dependency monitor reading a status page inherits that delay in full. Checking a real endpoint avoids the lag but introduces its own blind spot, because a public health endpoint that returns 200 tells you nothing about whether your key is rate-limited or your account is in a bad state.
The honest conclusion is that third-party API monitoring tells you who to blame quickly, not that you’ll always hear it first. That’s still worth a great deal at 9 a.m. when checkout is failing and you need to know within a minute whether to debug your own release or go read someone else’s incident page. Pair it with monitoring that watches your own critical path directly, and treat the dependency signal as the fastest available explanation rather than the earliest possible warning. Confusing the two is one of the more expensive monitoring anti-patterns, because it leaves you watching vendors closely and your own checkout not at all.
Key Takeaways
- A 200 from a status page proves only that the status page loaded — without a content assertion, the check is decorative.
- Assert on the vendor’s own incident vocabulary — matching the words they actually publish turns their page into a usable signal, and structured feeds beat HTML where they exist.
- Reserve Critical for money, auth, and infrastructure — everything else should degrade your status, not fail it, or the alerts stop being read.
- Label what you own — the first question in any incident review is whether the fault was yours, and the flag answers it before the discussion starts.
- Status pages lag and health endpoints are impersonal — dependency monitoring is the fastest route to a diagnosis, not a guarantee you hear about it first.
Want to know whether it’s you or your payment provider before support does? Start free with FlareWarden — dependency monitors with 40 provider integrations, 15 monitors, no credit card required.