DEV Community

Nicky Christensen
Nicky Christensen

Posted on

I Built a Monitoring Tool Because Uptime Checks Kept Lying to Me

If you deploy sites to Netlify, Vercel, Cloudflare Pages or pretty much any modern platform — you've probably set up some kind of uptime monitoring. Ping every minute, get an alert if the server doesn't respond. Pretty standard stuff.

I had the same setup across all my sites. And for a long time, I thought I was covered.

I wasn't.

The Problem

A few months back I pushed an update to one of my Nuxt apps on Netlify. Build passed, deploy preview looked fine, dashboard showed green. I moved on.

Turns out the site was broken for hours. Not down — the server was responding just fine. 200 OK on every request. But the JavaScript bundle the page needed wasn't loading, so the entire app was a blank page.

Here's what happened: the new deploy generated fresh hashed bundles. main.c8d13.js replaced main.a4f2c.js. But some CDN edge nodes were still serving the old HTML, which referenced the old filename. Browser tries to fetch main.a4f2c.js, gets a 404, and nothing renders.

My uptime monitor? Green the entire time. Because the HTML document loaded. 200 OK. Job done, as far as it was concerned.

It Keeps Happening

Once I started paying attention, I found this happens a lot more than you'd expect:

MIME type mismatches — Your JS file gets served as text/html by the CDN. Browser silently refuses to execute it. No console error you'd notice unless you're specifically looking. I had this on one of my sites behind Cloudflare for days without knowing.

Redirect chains that loop — CDN redirect + origin redirect + app redirect that conflict with each other. Browser hits the hop limit and gives up. Uptime tool sees the first 301 and moves on.

DNS still pointing at old infrastructure — After a migration, a subdomain resolves to the old origin. It responds with stale content from months ago. Technically "up." Practically useless.

All return 200. All invisible to standard monitoring.

Why I Built Sitewatch

I looked around for tools that caught this stuff. Most uptime monitors check if the server responds — and that's it. Some offer headless browser checks with Puppeteer, but they're slow, expensive, and fragile at any real scale. Not great when you're watching a bunch of sites.

What I needed was something in between. Goes deeper than a status code check, doesn't require a full browser session. Catches the broken deploy, the MIME type issue, the redirect loop — automatically.

So I built Sitewatch.

What It Does

Instead of just checking if your server responds, Sitewatch verifies whether your site actually works:

Asset verification — It fetches your page, parses the HTML, finds your JS and CSS bundle references, and checks each one. Correct status code? Correct MIME type? Actually loadable? If your HTML references a script that 404s or gets served as text/html, you get alerted.

Full redirect chain resolution — Follows redirects all the way to the final destination. Catches loops, unexpected landings, and chains that time out.

Content fingerprinting — Generates hashes of your page content and tracks them over time. If your homepage suddenly returns completely different content (stale cache, CDN error page that returns 200), the fingerprint shift triggers an alert.

Multi-region checks — CDN failures are often edge-specific. Your site works from Europe but serves broken assets in Asia. Sitewatch checks from multiple locations.

Confirmation before alerting — Uses a retry model before firing alerts. No 3am wake-ups because of a transient CDN blip.

It also classifies the root cause — infrastructure, deploy artifact, DNS, CDN config — so you know where to look instead of just knowing "something broke."

Some Technical Decisions

A few choices that might be relevant if you've thought about building something similar:

No headless browser. It's tempting because it's "real" rendering, but it doesn't scale well. Sitewatch parses HTML and makes targeted follow-up requests for critical assets. Gets you the meaningful signal without the overhead.

Stack detection. Different frameworks break differently. A Nuxt app has different failure patterns than a WordPress site or a Rails app behind Nginx. Sitewatch detects the tech stack from response headers and adjusts what it checks for.

Alert deduplication. If the same issue persists across checks, you don't want repeated alerts. Content fingerprints with a cooldown window — you get notified when something breaks and again when it's resolved, not every 5 minutes in between.

Try It

If you're running sites on modern deployment platforms — especially if you're managing multiple — this is a blind spot worth covering.

There's a free tier for one site. Takes about 30 seconds to set up: getsitewatch.com


That about wraps it up! If you found this useful, I'd love to know — leave a comment or connect with me on Twitter | LinkedIn or visit my website.

Top comments (0)