Third party monitoring: is it your code, or is it them?

Modern websites are assembled from other people’s services. Checkout runs on a payment provider, logins on an identity provider, images on a CDN, email on a delivery service and more and more features on an AI API. When one of them fails, your product fails with it – often while every monitor pointed at your own server stays green. Third party monitoring watches those dependencies, so the first question in an incident, “is it our code or is it them?”, is answered before anyone starts digging through logs. This guide explains what third party monitoring is, how it works, why provider status pages alone are not enough and how to set it up sensibly.

Your monitors can be green while your product is broken

A typical uptime monitor asks one question: did your server answer? That is the right question for your own infrastructure, but it says nothing about the services your product calls once a page has loaded. Your shop can render perfectly while card payments fail at the provider, your app can load while the identity provider rejects every login, and your pages can return 200 while the CDN that serves their images and scripts is down in half the world.

Third party monitoring fills that blind spot. It tracks the external providers behind your product and tells you which one failed, ideally through the same alert channels you already use for your own monitors. Just as important, it keeps the two kinds of incident apart: a provider outage is recorded as what it is, so it does not distort your own uptime statistics, and your team does not spend the first half hour of an incident searching for a bug in code that did not change.

What counts as a third party dependency?

Anything your product calls but does not run is a third party dependency. For most websites the list is longer than expected once you write it down: payment processors and their webhooks, cloud infrastructure such as object storage, managed databases and queues, CDNs and DNS providers, identity and single-sign-on services, transactional email and SMS gateways, search, maps, chat widgets, analytics and tag managers, and increasingly AI and machine-learning APIs.

Not all of them deserve the same attention. A failure in the payment provider stops revenue immediately; a failure in an analytics script costs some data. A useful first step is therefore an inventory with a criticality rating per component – critical, high, medium, low – and the specific part of each provider you depend on. You rarely need to watch “the cloud provider”; you need to watch object storage in one region and the managed database you actually run.

• Payments: card processing, checkout pages, webhooks
• Infrastructure: storage, databases, queues, DNS, CDN
• Identity: login, single sign-on, token refresh
• Communication: transactional email, SMS, push
• Embedded services: maps, chat, video, analytics, AI APIs

Find out before the status page does

Every larger provider runs a status page, and it is the authoritative source for what the provider has confirmed. It is rarely the fastest source. Status pages are updated by people who first have to verify that a problem is real and decide how to word it, so an incident is often visible in user reports, social media and customers’ own monitoring well before it is acknowledged – and smaller degradations sometimes never appear at all.

Good third party monitoring therefore combines several signals. Official status updates tell you what the provider admits and how it describes the impact. Aggregated user reports provide an early indication that something is wrong. And your own synthetic checks of the provider’s endpoints – or of your own pages that depend on them – tell you whether the problem affects you specifically. When all three agree, you can act with confidence; when only your own check fails, the problem is probably on your side.

Why not just subscribe to their status pages?

Subscribing to each provider’s status page by email or RSS is a reasonable start, and it costs nothing. It stops scaling quickly. Once your product depends on a dozen services, that is a dozen subscriptions in different formats, most of them reporting components you do not use, and none of them connected to the alerting your team responds to. A bookmarked status page does not wake anyone at 3 a.m., and an email about a dashboard incident at your payment provider is noise if you only use its card API.

A dedicated setup brings the providers into the same place as your own monitors, lets you choose the components that matter and shows both sides of an outage on one screen. The difference is less about data – much of it is public – than about filtering and routing: the right incident, for the right component, to the right person, without checking providers one by one.

How third party monitoring works

Whether you use a dedicated service or build it yourself, the workflow has the same three steps. First, list the providers you depend on – most tools let you search a catalogue by company or by product, so searching for an object-storage product finds its cloud provider. Second, select the components of each provider you actually use, for example payments and webhooks but not the merchant dashboard. Third, choose who is alerted and how, preferably through the alert contacts and channels you already use for your own monitoring.

payments      card payments, webhooks          critical
identity      login, token refresh             critical
cdn           images, static assets            high
email         order confirmations              medium
analytics     tag manager, tracking            low

From then on the system watches the status feeds of those components and notifies you when their state changes – not only up or down, but the specific state the provider published, such as “degraded performance” or “partial outage”. Many teams also manage the list in code, adding a provider in the same change that introduces the dependency, so the monitoring scope never lags behind the architecture.

Watch only the parts you use

Large providers split their status pages into dozens or hundreds of components and regions. Watching all of them guarantees alert fatigue: something, somewhere, is always degraded. Selecting only the components and regions you depend on keeps the signal clean, and it makes every alert actionable, because a notification means “something you use is affected”.

Review the selection whenever your architecture changes. A new region, a new API product or a migration away from a provider should be reflected in the monitored components, otherwise you will either miss incidents that matter or keep receiving alerts for services you no longer use.

Add your own synthetic checks of the critical path

Status feeds tell you about the provider; they do not prove that your integration works. An expired API key, a webhook endpoint that changed, a blocked IP range or a misconfigured redirect all break your checkout while the provider reports “all systems operational”. That is why mature setups add synthetic checks that exercise the critical path from the outside: load the checkout page, confirm the payment form renders, run a test-mode transaction where the provider offers one, or call a health endpoint that touches each dependency.

monitordefend Status-page subscriptions

One place for all providers

Alerts per component you usePartly

Signal before official acknowledgementPartly

Proves your own integration worksPartly

Two more habits help. Keep an eye on which external domains your pages load scripts, iframes and forms from: a new, unexpected domain can be a harmless marketing tag, a supply-chain compromise or a skimmer, and you want to know either way. And design for failure – timeouts, retries and graceful fallbacks for non-critical providers – so that a third party incident degrades a feature instead of taking the whole page down.

Keep third party incidents apart from your own uptime

A provider outage and an outage of your own server feel the same to a customer, but they mean different things for your team. If both land in the same uptime figure, the number stops telling you how reliable the systems you control really are, and service-level reports become arguments about whose fault a bad month was. Most dedicated tools therefore track third party services separately from your own monitors – with their own allowance and their own incident list – and simply show both side by side.

Do the same if you build the setup yourself: label each incident as internal or external, record the affected component and the impact on your users, and report the two figures separately. Over time this history is valuable in itself. Years of incident data across a provider show how often it degrades, how long its incidents last and how quickly it acknowledges them – a sober basis for deciding where redundancy is worth paying for and which dependency deserves a fallback first.

Respond to a provider incident

When a third party incident is confirmed, the response is mostly communication and mitigation, because the fix is not in your hands. Tell your support team and, if customers are affected, post a short note on your own status page or banner that names the affected feature without blaming anyone. Switch to a fallback where one exists – a second payment method, a cached version, a queue that retries later – and watch the provider’s updates for the resolution.

Afterwards, record the incident with its duration and impact. Over months, that history shows which providers cause the most disruption, which is the evidence you need to negotiate service credits, add redundancy or replace a dependency.

What monitordefend covers here

monitordefend is not a third party status aggregator: it does not track provider status pages or catalogue providers. It covers two parts of the picture for your own websites: the payment check loads your checkout URL every hour, detects the payment provider and can optionally run a Stripe test payment with a test key, and the integrity check flags new external script, iframe and form domains on your pages. Alerts are sent by email.

Frequently asked questions

What is third party monitoring?

It tracks the outside services your product depends on – payment processors, cloud infrastructure, CDNs, identity providers, email and AI APIs – and alerts you when one of them has an incident, ideally only for the components you actually use.

How is it different from monitoring my own website?

An uptime monitor asks whether your own server responded; third party monitoring asks whether the services behind it are healthy. Your checkout can fail while your server is fine because the payment provider is down. Running both tells you which side the problem is on.

Can I get alerts for only one part of a provider?

With most dedicated tools, yes. Providers split their status pages into components, and you choose which ones to track – for example card payments and webhooks, but not the merchant dashboard.

Is subscribing to provider status pages enough?

For one or two providers it can be. With a dozen dependencies the subscriptions become noisy and disconnected from your alerting, and official updates often arrive later than user reports or your own checks.

Should a provider outage count as my downtime?

Track it separately. Your users experience it as downtime, so record the impact, but keep it apart from your own uptime figures so you can see which incidents you can fix and which you need to mitigate.

Does monitordefend monitor third party providers?

Partly. It checks your checkout page hourly and detects the payment provider, and it flags new external script, iframe and form domains on your pages. It does not track provider status pages.

Related pages

• How to Monitor Payment Flows
• Stripe Checkout Monitoring
• How to Detect Website Changes
• Status page: how to create one and run it well
• Pricing