How to Monitor Third-Party Dependencies on Your Website

Your website loads dozens of external resources on every page view — CDN-hosted JavaScript, Google Fonts, analytics scripts, payment forms, chat widgets. When any of them fails, your page breaks. But most monitoring tools only check your server.

This guide shows you how to find every external dependency on your site and set up monitoring so you know when one fails — before your users report it.

Step 1: Find your dependencies

Before you can monitor dependencies, you need to know what they are. Most website owners don’t have a complete list of the external resources their pages load.

Option A: Use a free scanner

The fastest way is to scan your site with a tool that parses your HTML and lists every external resource:

Upsonar Dependency Scanner — paste your URL, get a full list of third-party resources grouped by type (scripts, stylesheets, fonts, images). No account required.

Option B: Check browser DevTools

1. Open your website in Chrome
2. Open DevTools (F12) → Network tab
3. Reload the page
4. Sort by “Domain” column
5. Everything that isn’t your domain is a third-party dependency

This gives you a snapshot, but it’s manual and doesn’t catch resources loaded conditionally (e.g., payment scripts that only load on checkout).

Option C: Check your HTML source

View your page source and look for external references:

<!-- Scripts from external domains -->
<script src="https://cdn.example.com/library.js"></script>

<!-- Stylesheets from CDNs -->
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter">

<!-- Images from external sources -->
<img src="https://images.cdn.example.com/photo.jpg">

Also check for dynamically loaded resources — scripts that load other scripts. The HTTP Archive found that the median inclusion chain depth is 3.4 levels, meaning your dependencies have dependencies of their own.

Step 2: Categorize by risk

Not all dependencies are equal. Prioritize monitoring based on impact:

Focus monitoring on the critical and high-risk resources first.

Step 3: Choose a monitoring approach

Approach 1: Automatic dependency monitoring (recommended)

Tools like upsonar parse your HTML on every check and automatically monitor all external resources. When you add a new widget or your CMS loads a new plugin, it’s picked up automatically.

Pros: Zero maintenance, catches new dependencies, monitors everything Cons: Less granular control over individual resource thresholds

How to set up with upsonar:

1. Create a free account
2. Add your website URL
3. Dependencies are discovered and monitored automatically on every check

That’s it. Upsonar parses your HTML, extracts all external resources, and checks each one from 9 global regions. You’ll get alerts when any dependency fails.

Approach 2: Manual endpoint monitoring

Set up individual HTTP monitors for each critical dependency URL. Works with any monitoring tool (UptimeRobot, Pingdom, etc.).

Pros: Works with any tool, granular control per resource Cons: Manual setup, you must know every URL, doesn’t catch new dependencies, requires separate monitor per resource

To set this up:

1. List your critical dependencies from Step 1
2. Create a monitor for each CDN endpoint, script URL, and API domain
3. Remember to update the list whenever your site changes

Approach 3: Real User Monitoring (RUM)

RUM tools (Datadog, New Relic, Sentry) collect performance data from actual user browsers. They can detect third-party failures as they happen in real user sessions.

Pros: Real user data, catches issues per browser/region/device Cons: Reactive (you learn about failures after users experience them), expensive, requires code instrumentation

Step 4: Set up multi-region checks

A CDN might work in North America but fail in Asia. A font service might be fast in Europe but timeout in Australia. Single-region monitoring gives you a false sense of security.

When setting up monitoring, check from at least 3-5 regions that match where your users are. If your users are global, monitor from regions across multiple continents.

Upsonar checks from 9 regions (Sydney, New York, Singapore, Amsterdam, Bangalore, Frankfurt, London, San Francisco, Toronto) and only alerts when a failure is confirmed from multiple locations — reducing false positives from regional network issues.

Step 5: Configure meaningful alerts

Dependency failures need different alert handling than server downtime:

For critical dependencies (payment, auth): alert immediately via the fastest channel — Telegram, SMS, or a webhook to your incident management tool.

For high-risk dependencies (CDN, fonts): alert after confirmation from 2+ regions. A brief CDN blip in one region might resolve in seconds.

For medium-risk dependencies (analytics, tracking): consider batching alerts or only alerting during business hours. A broken analytics script at 3 AM doesn’t need to wake anyone up.

Common third-party failure patterns to watch for

SSL certificate expiry on CDN domains. Third-party services sometimes let their certificates expire. Your monitoring should check the SSL status of dependency domains, not just your own.

DNS resolution failures. If a CDN’s DNS goes down, all resources hosted there become unreachable. This was the root cause of the Akamai outage in July 2021 that took down banks and airlines worldwide.

Slow responses that aren’t technically “down.” A script that takes 15 seconds to load won’t trigger a “down” alert, but it makes your page unusable. Monitor response times, not just availability.

Region-specific failures. CDN edge nodes fail independently. A resource might be perfectly available in your region but down in the region where your users are. This is why multi-region monitoring matters.

What to do when a dependency fails

When a third-party dependency goes down, you typically can’t fix it — it’s someone else’s service. But you can respond:

1. Verify the scope — is it down globally or in specific regions? Check from multiple locations.
2. Check the provider’s status page — most CDNs and services have status pages.
3. Assess user impact — does the dependency block the page, or is it a non-critical resource?
4. Consider a fallback — for fonts, use font-display: swap. For scripts, use async or defer. For CDNs, consider having a fallback origin.
5. Communicate — if user experience is affected, update your own status page.

The key is knowing about the failure before your users report it. That’s what dependency monitoring gives you — visibility into the parts of your site you don’t control.

Related: What Is Website Dependency Monitoring — the why behind monitoring third-party resources. And Beyond Soft 404s — five more ways your site can be broken while returning 200 OK.