How to Monitor CDN and Static Asset Availability

Most uptime monitoring stops at the front door. You point a check at https://yoursite.com, it returns a 200, and the dashboard goes green. But a modern web page is not a single document — it's an HTML shell that pulls in a dozen or more separate files from a content delivery network: JavaScript bundles, stylesheets, web fonts, images, and icons. When one of those assets fails, your status-code check still sees a healthy 200, while real users see a page that's unstyled, frozen, or missing half its content.

This is the classic "up but wrong" failure, and CDN static assets are where it bites hardest. The HTML loads, the monitor is happy, and the bug report comes in from a customer instead of your alerting. In this guide we'll cover why these failures are so sneaky, exactly what to monitor, the techniques that actually catch the problem, and a practical checklist you can act on today.

Why CDN and static-asset failures are so sneaky

When a browser loads your site, it fetches the HTML first, then issues a fresh request for every referenced asset. Each of those is an independent network call to a CDN edge node, and each can fail independently of the page itself. A few of the ways this goes wrong:

The asset 404s after a deploy. Your build produces hashed filenames like app.4f9c2a.js. If the HTML references a new hash but the CDN cache or origin still has the old one — or vice versa — the browser requests a file that doesn't exist. The page shell loads; the app never boots.
The asset is stale. An aggressive cache TTL or a missed purge means the CDN keeps serving last week's JavaScript against this week's HTML. No error, just subtly broken behavior.
Wrong content-type or cache headers. A misconfigured CDN rule serves your JavaScript as text/plain or your fonts with a restrictive CORS or cache policy. The file downloads with a 200 but the browser refuses to execute or render it.
SSL trouble on the CDN hostname. Your CDN often lives on a separate hostname (cdn.example.com, an object-storage URL, or a third-party provider) with its own certificate. When that certificate expires, every asset request fails even though your main domain's certificate is fine.
A regional POP fails. CDNs serve from points of presence around the world. One edge location can return errors or stale bytes while every other region stays healthy — invisible to a check that only runs from one place.

In all of these cases, a simple check against the page URL returns 200 and tells you everything is fine. The only reliable way to know is to request the assets the way a browser would. This is a specific case of the broader pattern we cover in the most common causes of website downtime — many real outages never change the HTTP status of your homepage.

What you should actually monitor

"Monitor the CDN" is too vague to act on. Break it into the concrete things that fail, and put a check on each one.

Critical asset URLs

Identify the handful of assets your site genuinely cannot work without: the main JavaScript bundle, your primary stylesheet, the web font your layout depends on, and any hero or logo image that signals "the page rendered." Open your site, look at the network tab, and copy the full CDN URLs for these files. These are your monitoring targets — not the page, the assets.

Cache-busting and hashed filenames after deploy

If your assets use content hashes in their filenames, the exact URL changes on every deploy. You have two sensible options. Monitor a stable, unhashed entry point if you publish one (for example a latest or versioned manifest URL), or update the monitored URL as part of your deploy pipeline using the API. Either way, the goal is the same: confirm that the asset the current HTML references is actually being served, not just that some asset exists.

SSL on the CDN hostname

Treat your CDN hostname as a first-class certificate to watch. It frequently renews on a different schedule (or through a different provider) than your apex domain, which makes it easy to forget until it lapses. We go deep on this in our guide to SSL certificate monitoring — the short version is that every HTTPS asset check should also be validating the certificate behind it.

Origin fallback and third-party dependencies

If your CDN is configured to fall back to an origin server when the edge misses, test that path too — a broken origin only surfaces when the cache expires. And don't forget assets you don't control: the analytics script, the payment widget, the map tile server, the font loaded from a public provider. A <script> tag pointing at someone else's domain is a dependency that can take your page down. Monitoring those is exactly the subject of third-party dependency monitoring.

Version and integrity drift

If you pin an asset to a specific version or use Subresource Integrity (SRI) hashes, a silent change to that file will break your page (with SRI) or quietly ship altered code (without it). You want to know the moment a "fixed" asset stops matching what you expect.

Techniques that actually catch the problem

With the targets identified, here are the techniques that turn "we think the CDN is fine" into "we'd be alerted within a minute if it weren't."

Monitor the asset URL directly

The foundational move: create a check whose URL is the asset itself, not the page that references it. A request to https://cdn.example.com/app.4f9c2a.js exercises the exact same path a browser takes — DNS resolution of the CDN hostname, TLS handshake, the edge node's response — and a non-200 status fails the check immediately. This alone catches the most common failure, the post-deploy 404.

Assert the content with keyword and regex checks

A 200 status only proves the CDN returned something. To prove it returned the right something, assert on the body. Pick a stable string that should always appear in the file — a function name in your bundle, a CSS selector in your stylesheet, a version comment — and require it to be present. If the CDN serves an error page, a stale build, or a truncated file with a 200 status, the keyword check still fails. Our guides on keyword monitoring and broader content monitoring walk through the contains, not-contains, and regex modes in detail.

Detect silent changes with SHA-256 content hashing

For a pinned, immutable asset — one that should be byte-for-byte identical until you intentionally deploy a new version — content-hash monitoring is the strongest signal you can get. CronAlert computes a SHA-256 hash of the response body on every check and stores a baseline. If the hash ever changes, you're alerted. For an asset that's supposed to be frozen, any change at all means the CDN is serving a corrupted, altered, or unexpectedly updated file. This is how you catch the failures that keyword checks miss because the file still contains your expected string but isn't actually the same file.

Check from multiple regions

Because CDN failures are often regional, a single-location check is a blind spot. Running the same asset check from several geographic regions surfaces the case where one POP serves stale or broken bytes while the rest are healthy. The catch is that one momentarily slow edge node shouldn't page you at 3 a.m., which is why quorum logic matters — alert when a meaningful fraction of regions agree something is wrong, not on the first hiccup. We cover the tradeoffs in multi-region uptime monitoring and how to keep it quiet in reducing false-positive alerts.

Watch response time, not just availability

A CDN that's slow is a CDN that's degrading. If your main bundle that normally returns in 80ms suddenly takes two seconds, users are staring at a blank page even though nothing technically "failed." Set a response-time threshold on your critical asset checks so slow degradation pages you before it becomes a full outage. Picking sane numbers here is its own small art — see choosing monitor timeout thresholds.

A note on scope: what HTTP checks can and can't see

It's worth being precise about what this kind of monitoring covers. CronAlert performs HTTP and HTTPS checks and heartbeat (cron) checks. It does not do raw TCP socket checks, port scanning, or low-level DNS-protocol probing. For CDN and static asset monitoring, that's a feature rather than a limitation: you want to test the asset exactly the way a browser fetches it — a real HTTP request to the asset URL, resolving the CDN hostname, completing the TLS handshake, and reading the response body.

So when we talk about "checking the CDN hostname," what's actually happening is an HTTP request to an asset on that hostname. That request implicitly resolves DNS and validates SSL as part of the round trip, and that's what surfaces the real-world failure your users would hit. If you want monitoring focused on the resolution layer specifically, that's a different discipline — see DNS monitoring. And if your CDN is built on Cloudflare's edge, our notes on monitoring Cloudflare Workers are a useful companion.

How CronAlert helps

CronAlert is agentless, Cloudflare-edge uptime monitoring, and the feature set lines up directly with the techniques above:

Per-asset HTTP/HTTPS checks. Point a monitor at each critical asset URL. A non-200 from the CDN fails the check and triggers alerts.
Keyword, string, and regex matching. Assert that an expected string is present (or that an error string is absent) in the asset body, so a 200 with the wrong content still fails.
SHA-256 content-hash change detection. Baseline a pinned asset and get alerted the instant its bytes change — corrupted, altered, or unexpectedly redeployed.
SSL monitoring on the CDN host. Every HTTPS check validates the certificate and tracks its expiry, so a CDN-hostname certificate lapse never catches you off guard.
Multi-region checks with quorum. On the Team plan, checks run from five Cloudflare edge regions with quorum logic so a single flaky POP doesn't cause a false alarm.
Response-time thresholds. Catch a degrading CDN before it becomes an outage.

Plans scale with your needs. The free plan ($0) includes 25 monitors at a 3-minute interval, SSL monitoring, content checks, a status page, the full REST API, and 7-day retention — enough to monitor every critical asset on a small site. Pro ($5/month, or $4/month billed annually) bumps you to 100 monitors at a 1-minute interval with every alert channel. Team ($20/month) adds the five-region, quorum-based multi-region checks. Alerts can route to email, Slack, Discord, Microsoft Teams, Telegram, PagerDuty, Opsgenie, Splunk On-Call, webhooks, and PWA push. The full REST API is available on every plan, and there's an MCP server for Claude Code, Cursor, and Windsurf if you'd rather manage monitors from your editor.

A practical checklist

Work through this list and you'll have meaningful coverage of your CDN and static assets:

Open your site, inspect the network tab, and list the assets the page genuinely cannot work without (main JS bundle, primary CSS, key fonts and images).
Create an HTTP check for each critical asset URL — the asset itself, not the page.
Add a keyword or regex assertion to each check using a stable string from inside that file.
Enable SHA-256 content-hash detection on any asset that's supposed to stay frozen between deploys.
Add a check for your CDN hostname's SSL certificate (any HTTPS asset URL on that host covers it).
Add checks for third-party assets you depend on but don't control (analytics, payments, maps, public fonts).
If global availability matters, enable multi-region checks with quorum on your most critical assets.
Set a response-time threshold so a slow CDN pages you before it becomes a full outage.
Wire the URL-update step into your deploy pipeline (via the API) if your filenames are content-hashed.
Route alerts to a channel your team actually watches, and tune thresholds to avoid noise.

Frequently asked questions

Why does my page load fine but appear broken when an asset fails?

Browsers fetch your HTML first, then fetch every referenced asset (JavaScript bundles, stylesheets, fonts, images) as separate requests. If the HTML returns 200 but a CSS file on your CDN 404s, the page structure loads but appears unstyled or non-interactive. A status-code check against the page URL never sees the failure because it never requests the assets. You have to monitor the asset URLs directly to catch these "up but wrong" failures.

How do I detect when a CDN serves a stale or corrupted asset?

Use content-hash monitoring. CronAlert computes a SHA-256 hash of the response body on every check and alerts when it changes. For a pinned, hashed asset that should never change, any hash difference means the CDN is serving a corrupted, altered, or stale version. You can also use keyword or regex checks to assert that a known string still appears in the file.

Should I monitor each asset from multiple regions?

Yes, if availability matters globally. CDNs serve from regional points of presence, and a single POP can fail or serve stale content while every other region is healthy. A check from one location would miss it entirely. CronAlert's Team plan runs checks from five Cloudflare edge regions with quorum logic, so a single flaky POP does not trigger a false alarm but a real regional outage does.

Can CronAlert check the SSL certificate on my CDN hostname?

Yes. Point a monitor at an asset URL on your CDN hostname (for example https://cdn.example.com/app.js) and CronAlert checks the TLS certificate on every HTTPS request. It tracks the expiry date and alerts before the certificate lapses. CDN hostnames often use different certificates than your main domain, so monitor them separately.

Does CronAlert do raw TCP or port-level probing of a CDN?

No. CronAlert performs HTTP and HTTPS checks and heartbeat (cron) checks only. It does not do raw TCP socket checks, port scanning, or low-level DNS-protocol probing. For CDN and static asset monitoring this is exactly what you want: you make a real HTTP request to the asset URL, which is the same path a browser takes, and you validate the status code, response body, content hash, SSL certificate, and response time.

Start monitoring your CDN and static assets

Don't let a 200 on your homepage lull you into thinking everything works. The assets your CDN serves are where "up but broken" lives, and they're easy to monitor once you point your checks at the right URLs. Create a free CronAlert account and put an HTTP check on each of your critical assets — with keyword assertions, content-hash detection, and SSL monitoring — in a few minutes. New to all this? Start with what uptime monitoring is, and if you build APIs, pair this with API endpoint monitoring.