DEV Community: Sitewatch

We Built a Free Website Health Scanner. Here's What It Finds on Most Sites

Sitewatch — Thu, 16 Apr 2026 09:24:13 +0000

Your site is up. But is it healthy?

We just shipped a free website health scanner at getsitewatch.com/scan. No signup. No email. Just paste a URL and get a full report in about 20 seconds.

We built it because we kept running into the same problem: developers and site owners had no quick way to check if their site was actually working — beyond just loading the page in a browser and eyeballing it.

Here's what the scanner checks, why each issue matters, and what we typically find when people scan their production sites.

1. Broken Assets (Images, Scripts, Stylesheets)

What we check: Every image, script, and stylesheet referenced in your HTML. Does it actually load? Or does it return a 404, 403, or 500?

What we typically find: This is the most common issue. Roughly 3 out of 10 sites we've scanned have at least one broken asset. Usually it's an image that was moved or renamed, a script that was deleted during a deploy, or a stylesheet that references a font file that no longer exists.

Why it matters: A missing image is cosmetic. A missing JavaScript file can break your entire page. If your checkout depends on a script that returns 404, your checkout is dead — but your server still returns 200 OK and your uptime monitor says everything is fine.

Quick manual check:

# Find broken images on any page
curl -s https://yoursite.com | grep -oP 'src="[^"]*"' | while read -r src; do
  url=$(echo "$src" | tr -d '"' | sed 's/src=//')
  [[ "$url" != http* ]] && url="https://yoursite.com$url"
  status=$(curl -o /dev/null -s -w "%{http_code}" "$url")
  [[ "$status" != "200" ]] && echo "BROKEN ($status): $url"
done

Or just paste your URL at getsitewatch.com/scan — it does this automatically for every asset type.

2. Mixed Content

What we check: Does your HTTPS page load any resources over plain HTTP?

What we typically find: Common on sites that migrated to HTTPS but still have hardcoded http:// URLs in the database, templates, or third-party embeds. WordPress sites are particularly prone to this after an SSL migration.

Why it matters: Modern browsers silently block mixed content. No error. No warning to the user. Images just don't render. Scripts don't execute. Fonts fall back to system defaults. Your site looks broken, but only to your visitors — not to you in your browser with cached assets.

Quick manual check:

curl -s https://yoursite.com | grep -oP '(src|href)="http://[^"]*"'

If this returns anything on an HTTPS site, those resources are being blocked.

3. SSL Certificate Issues

What we check: Is your certificate valid? When does it expire? Is the chain complete? Does it match the domain?

What we typically find: Certificates expiring within 30 days without auto-renewal configured. Incomplete chains where the intermediate CA is missing — site works in Chrome but throws warnings in Safari and on mobile. Certs that don't match the domain after a server migration.

Why it matters: An expired or misconfigured cert turns your site into a browser warning page. But the failure window before it fully expires is worse — some browsers are more forgiving than others, so you get inconsistent behavior that's hard to debug. According to Keyfactor's 2024 report, 88% of companies experienced an unplanned outage from an expired certificate in the past two years.

Quick manual check:

# Check when your cert expires
echo | openssl s_client -servername yoursite.com -connect yoursite.com:443 2>/dev/null | openssl x509 -noout -enddate

The scanner flags certificates expiring within 30 days and checks chain completeness automatically.

4. Missing Security Headers

What we check: CSP (Content-Security-Policy), HSTS (Strict-Transport-Security), X-Frame-Options, X-Content-Type-Options, Referrer-Policy.

What we typically find: This is the most universally failed check. The vast majority of sites we scan are missing at least two critical security headers. HSTS and CSP are the most commonly absent.

Why it matters:

No HSTS: Visitors can be MITM'd on their first visit before the redirect to HTTPS happens.
No CSP: No defense against XSS attacks injecting scripts into your page.
No X-Frame-Options: Your site can be embedded in an iframe on a malicious page (clickjacking).
No X-Content-Type-Options: Browsers may MIME-sniff responses and execute files as scripts that weren't intended to be scripts.

Quick manual check:

curl -sI https://yoursite.com | grep -iE "strict-transport|content-security|x-frame|x-content-type|referrer-policy"

Empty result = no security headers. The scanner shows which ones are missing and what each one protects against.

5. Schema & SEO Issues

What we check: JSON-LD structured data validation, canonical URLs, Open Graph tags, meta descriptions, title tags.

What we typically find: Missing or malformed JSON-LD is common — especially after a CMS update or template change. Missing Open Graph tags mean your site looks bare when shared on LinkedIn, Twitter, or Slack. Duplicate or missing canonical URLs confuse search engines about which page to index.

Why it matters: These don't break your site visually, but they break your site's reach. Bad schema means Google can't generate rich snippets. Missing OG tags mean your links look unprofessional when shared. Wrong canonicals mean your SEO juice is split across duplicate pages.

6. Discoverability

What we check: Does robots.txt exist and is it valid? Is there a sitemap.xml and does it return 200?

What we typically find: Missing sitemaps are surprisingly common — especially on SPAs and Jamstack sites where nobody thought to generate one. Occasionally we find robots.txt files that accidentally Disallow: / — blocking all search engines from the entire site.

Why it matters: Without a sitemap, search engines crawl your site less efficiently. A misconfigured robots.txt can de-index your entire site. These are 5-minute fixes with massive impact.

What the Report Looks Like

The scanner returns a prioritized report with severity rankings:

Critical — Things actively breaking your site for visitors (broken scripts, expired SSL)
Warning — Things silently degrading the experience (mixed content, missing security headers)
Info — Things that affect SEO and discoverability (missing schema, no sitemap)

Every finding includes a plain-language explanation of what it is, why it matters, and how to fix it. No jargon dumps. No "error code 4xx on subresource" without context.

Why We Built This

We run Sitewatch — a website monitoring tool that continuously checks if sites actually work, not just if they respond.

But continuous monitoring is a commitment. You need to sign up, configure checks, set up alerts. That's the right move for production sites — but sometimes you just want a quick answer: is my site healthy right now?

The scanner is that quick answer. Think of it as a one-time checkup versus ongoing monitoring. The doctor visit versus the daily vitamin.

It's completely free. No email required. No credit card. No "enter your email to see the full results" nonsense.

Scan your site now →

What Happens After the Scan

If your site is clean — great. You just got peace of mind in 20 seconds.

If it found issues — the report tells you exactly what to fix and why, ordered by severity. Most of the critical issues (broken assets, SSL problems) can be fixed in under an hour.

And if you want to make sure these issues don't come back after the next deploy, that's where continuous monitoring comes in. Sitewatch checks your site on an ongoing basis and alerts you before your users notice something is broken.

But the scan itself? No strings attached. Use it, fix what it finds, move on.

Try it on your own site and drop your health rating in the comments — I'm curious what people find.

getsitewatch.com/scan

We Stopped Trusting Uptime Metrics. Here's What We Monitor Instead.

Sitewatch — Tue, 31 Mar 2026 11:31:26 +0000

We're going to make a claim that might sound controversial:

Uptime monitoring and website monitoring are not the same thing. Most people use the terms interchangeably. They shouldn't.

Uptime monitoring answers: "Did the server respond?"
Website monitoring answers: "Does the site work?"

Those sound similar. They're not. And the gap between them is where most silent failures live.

What uptime monitoring actually does

Let's be specific about what a typical uptime monitoring tool checks. There's no ambiguity here — this is the standard model that tools like UptimeRobot, Pingdom, Better Stack, and most others follow:

Send an HTTP request to your URL
Receive a response
Check the status code
If it's 200 OK → mark as healthy
If it's 5xx or timeout → mark as down
Report uptime percentage

That's it. That's the check.

It tells you whether your server is alive and responding to requests. It does that well. And for a long time, that was enough — because if the server was up, the site worked.

That's no longer true.

What uptime monitoring does NOT check

Here's a non-exhaustive list of things a standard uptime check will miss:

Asset integrity. Your HTML loads, but the JavaScript bundle it references returns 404 because you deployed and the CDN still serves old HTML pointing to deleted files. The page is a blank white screen. Status code on the document: 200.

MIME types. Your server returns a JS file with Content-Type: text/html. The browser downloads it, reads the header, silently refuses to execute it. Your SPA never boots. Status: 200.

Redirect chains. Your site redirects /page → /page/ → /page → /page/. The browser gives up after 20 hops. Your uptime tool followed the first redirect, got a 200, and moved on.

Content correctness. Someone changed your homepage in the CMS at 2am. Or your CDN started serving content from the wrong origin after a migration. The page loads — it's just the wrong page. Status: 200.

Third-party dependencies. Stripe's JS fails to load. Your checkout renders as an empty div. Your auth provider is down. Users can't log in. Your page loaded fine — the broken resource is on someone else's domain.

Regional divergence. Your site works from US-East. In Frankfurt, the CDN edge serves stale cached assets from three deploys ago. Single-region uptime checks never see this.

Every single one of these returns 200 OK. Every single one passes a standard uptime check. Every single one is broken for users.

What website monitoring checks instead

Website monitoring starts where uptime monitoring stops. Instead of asking "did the server respond?", it asks "did the response constitute a working page?"

That means:

Treating the HTML document as a manifest, not a destination. The document is step one. Website monitoring follows up — do the JS and CSS bundles it references actually load? Do they return the right MIME types? Do they return valid status codes?

Following redirect chains to completion. Not just the first hop. The full chain. Does it resolve? Does it loop? Does it end somewhere unexpected?

Fingerprinting content over time. If the response body changes without a deployment, you want to know. Content fingerprinting with SHA-256 hashes catches silent CMS edits, CDN origin drift, and cache poisoning.

Checking from multiple regions. CDN failures are regional by nature. A site can be perfect in one location and broken in another. Website monitoring runs the full check suite from multiple geographic locations independently.

Classifying root cause. Not just "something is wrong" but "why." Is this a deployment artifact? A CDN cache issue? A DNS drift? An application error? Root cause classification turns an alert into actionable information.

A practical comparison

Here's the same scenario through both lenses:

Scenario: You deploy a Nuxt 3 app to Vercel. The build succeeds. But a CDN edge node in Europe still serves the previous HTML, which references app.7fb2e.js. That file was deleted in the new build.

	Uptime monitoring	Website monitoring
HTTP status	200 OK ✅	200 OK (document)
Asset check	Not checked	`app.7fb2e.js` → 404 ❌
MIME validation	Not checked	N/A (asset missing)
Multi-region	Single region ✅	EU: broken ❌, US: ok ✅
Alert	None	Incident: deployment artifact missing, EU region
Root cause	N/A	CDN cache stale, Vercel ISR
User impact	Unknown	European users see blank page

Same site. Same moment. Completely different picture.

They're complementary, not competing

We want to be clear about something: we're not saying uptime monitoring is useless. It's not. You absolutely need to know when your server is down. A 503 or a timeout is a real outage and you need to know about it immediately.

The problem is treating uptime monitoring as sufficient. It's one layer. It catches one type of failure. The failures it misses — the "200 OK but broken" failures — are increasingly the ones that actually hurt users.

The monitoring stack for a modern web application should have both:

Uptime monitoring → Is the server alive? Is it responding? Is the infrastructure running?

Website monitoring → Does the site work? Are assets loading? Is the content correct? Does it work everywhere?

If you only have the first, you have a blind spot. And it's the kind of blind spot where your dashboard says 99.9% uptime while your users are staring at blank pages.

This is why we built Sitewatch

Sitewatch is website monitoring. Not uptime monitoring. The distinction matters to us because it's the entire reason the product exists.

We check asset integrity, MIME types, redirect chains, content fingerprints, and multi-region consistency. When something breaks, we classify root cause — infrastructure, application, or content delivery — and provide fix guidance tailored to your tech stack.

Every check runs a 2-of-3 retry confirmation model so you don't get woken up at 3am for a transient CDN hiccup. Duplicate alerts are deduplicated with SHA-256 fingerprinting and a 30-minute cooldown.

Free tier for 1 site. No credit card. Takes 30 seconds: getsitewatch.com

Uptime monitoring tells you the server is alive. Website monitoring tells you the site works. They're not the same question — and the answer to one doesn't imply the answer to the other.

Uptime Monitoring Is a Lie. Here's What It Actually Misses

Sitewatch — Sat, 28 Mar 2026 08:16:01 +0000

If your uptime dashboard says 99.9%, congratulations. Your server responded to pings 99.9% of the time.

That number says nothing about whether your users could actually use your site.

The monitoring industry has spent two decades optimizing for the wrong metric. We got really, really good at answering "did the server respond?" — and never moved on to the question that actually matters: "does the site work?"

The gap nobody talks about

There's a growing space between what monitoring tools measure and what users actually experience. It's getting wider, not smaller, because modern web architecture is getting more complex.

Ten years ago, your site was a server rendering HTML. If the server was up, the site worked. Uptime monitoring made sense.

Today, your "site" is a document that references hashed JS bundles from a CDN, loads third-party scripts from five different domains, runs through an API gateway, gets assembled by edge functions, and depends on a headless CMS for content. The server responding is step one of a twelve-step process.

Uptime monitoring still checks step one.

What "up" actually looks like in production

Let's say your uptime monitor pings your site every 60 seconds. Here's what it does:

Sends an HTTP request
Gets a response
Checks the status code
If it's 200, marks the site as healthy

Here's what it doesn't do:

Check if the JavaScript bundles the page references actually exist
Verify that assets are served with correct MIME types
Follow redirect chains beyond the first hop
Compare the response content to what it looked like yesterday
Check whether third-party dependencies loaded
Verify the page works from more than one location

Every single one of those unchecked items is a real failure mode that happens in production regularly. And every single one returns HTTP 200 OK.

Three failure patterns your uptime tool will never catch

The stale CDN.
You deploy. Your CDN edge nodes in some regions still serve old HTML. That HTML references JS bundles that no longer exist. The document loads, the scripts 404, nothing renders. Some users get it, others don't. Your monitor checks from one region and sees a healthy page.

The MIME mismatch.
A misconfigured proxy serves your JavaScript file with Content-Type: text/html. The browser downloads it, reads the header, and silently refuses to execute it. No console error. No failed network request. Just a page that never initializes. Status: 200.

The silent dependency failure.
Your site loads fine. Your payment provider's JS doesn't. The checkout button renders as an empty container. Your page looks complete. It just can't process transactions. Your uptime tool checks your domain — the broken resource is on someone else's.

None of these are edge cases. They're happening on production sites right now. The sites report 99.9% uptime while users experience broken functionality.

Why the industry is stuck

Uptime monitoring became a commodity. Dozens of tools compete on the same feature set: more check locations, faster intervals, prettier dashboards. But they all measure the same thing — did the server respond with a non-error status code.

The underlying assumption hasn't changed since 2005: a healthy HTTP response means a healthy website.

That assumption was wrong then. It's dangerously wrong now.

Part of the reason is that deeper monitoring is harder. Verifying asset integrity means parsing HTML, extracting resource references, and checking each one. Following redirects properly means handling cookie state and user agent differences. Detecting content drift means fingerprinting responses over time. Checking from multiple regions means actually running infrastructure in multiple regions.

It's more expensive to build and more expensive to run. So most tools don't do it.

What would real monitoring look like?

If we started from scratch — knowing what we know about how modern sites actually fail — monitoring would look completely different.

It would treat the HTML document as a manifest, not a destination. The document is the starting point. The real question is whether everything it references actually loads and works.

It would verify, not assume. Instead of trusting that a 200 means everything is fine, it would check that JS bundles return the right MIME type, that redirects resolve instead of loop, that the content hasn't silently changed.

It would check from multiple locations. CDN failures are regional. A site can be perfectly functional in one region and completely broken in another. Single-region checking misses this entirely.

It would distinguish between "responded" and "works." Two fundamentally different states that current monitoring treats as one.

It would reduce noise, not create it. False positives at 3am erode trust faster than anything. A proper confirmation model — checking multiple times before alerting — means you only get woken up for real problems.

This is why we built Sitewatch

We got tired of the gap between what uptime dashboards reported and what users actually experienced. So we built monitoring that checks whether your site actually works — not just whether the server responds.

Sitewatch monitors asset integrity, MIME types, redirect chains, content fingerprints, and multi-region consistency. When something breaks, it classifies the root cause — infrastructure, application, or content delivery — so you know what to fix, not just that something is wrong.

Free tier for 1 site. No credit card. Check it out if you've been burned by a green dashboard that was lying to you.

Uptime was the right metric for a simpler web. The web isn't simple anymore. The monitoring needs to catch up.

This is the story behind how Sitewatch was built — and why shipping faster with AI made production monitoring even more critical.

Sitewatch — Fri, 27 Mar 2026 11:48:06 +0000

Nicky Christensen

Mar 27

AI Wrote 70% of My Production Codebase. Here's Why That Actually Worked.

#ai #claudecode #webdev #javascript

Comments 2

4 min read

Your CI Is Green. Your Site Might Not Be.

Sitewatch — Fri, 27 Mar 2026 08:43:16 +0000

Your CI is green. The deploy finished. Uptime is still 100%.

And your users might still be staring at a blank page.

CI tells you whether your build completed. It does not tell you whether production is serving the right content, with the right assets, from the right place.

The failures that hurt most are rarely total outages. They're partial, silent, and easy to miss if all you track is status codes and deploy success.

The problem with green dashboards

A green deploy only proves your pipeline finished. It doesn't prove users can load your scripts, follow your redirects, or complete a flow. Production can be broken while every dashboard stays green.

Here's what to actually verify — before your users find the problem for you.

1. Verify your asset hashes resolve

After a deploy, your HTML references new hashed filenames — main.c8d13.js, styles.7fb2e.css. If your CDN is still serving the old HTML at some edge locations, those references point to files that no longer exist.

The real problem is the mismatch between the HTML document and the assets it expects — and this is one of the most common silent failures after deploys.

What to check:

# Fetch your page and extract script/stylesheet URLs
curl -s https://yoursite.com | grep -oP '(src|href)="[^"]*\.(js|css)"'

# Then verify each asset returns 200
curl -I https://yoursite.com/_next/static/chunks/main.c8d13.js

Check both the homepage and one or two critical routes — they can reference different bundles. You're looking for 200 (not 404) and a fast response (not a timeout suggesting the file is missing behind a fallback).

When this matters most: Platforms with CDN edge caching (Netlify, Vercel, Cloudflare Pages), especially when your HTML cache TTL outlives your deploy frequency.

2. Check MIME types on your JS and CSS

A JavaScript file served with Content-Type: text/html will be silently blocked by the browser. Your page loads. Your scripts don't execute. No visible error unless you inspect the network tab.

What to check:

curl -I https://yoursite.com/assets/app.js | grep content-type
# Should be: content-type: application/javascript
# Not: content-type: text/html

Do this for your main JS bundle and your primary CSS file at minimum.

When this matters most: Sites behind Nginx with try_files directives that fall back to index.html for everything, or CDNs that replace 404s with branded HTML error pages.

3. Follow your redirect chains

Don't just check that your URL responds — check where it ends up.

What to check:

curl -sIL https://yoursite.com/important-page | grep -E "(HTTP/|location:)"

Look for:

More than 3 redirects (excessive)
A loop (same URL appearing twice)
Landing on an unexpected destination (generic error page, wrong subdomain)
Final status is not 200
Protocol normalization fighting itself (HTTP → HTTPS → HTTP)

When this matters most: After changing DNS, CDN rules, SSL configuration, or adding plugins/middleware that modify routing. Especially common when redirect rules at different layers (CDN, origin, application) don't agree with each other.

4. Verify from a different region

Your site works from your location. That doesn't mean it works everywhere.

CDN cache invalidation failures are regional — your local edge got the purge, Frankfurt didn't. Your users in Europe see stale HTML referencing deleted assets while your dashboard says green.

What to check:

The real test is comparing actual responses from multiple locations. If you have a cloud instance in another region, run the same checks from there. A VPN works too.

Compare across regions:

Does the HTML reference the same asset hashes?
Do the same assets return 200?
Do redirect chains land on the same destination?
Do cache headers (age, x-cache, cf-cache-status) differ?

# Quick DNS sanity check from your machine
dig +short yoursite.com
# Useful for catching post-migration drift, but not a substitute
# for actually fetching content from multiple locations

When this matters most: After DNS changes, CDN migrations, cache purges, and any deploy to a platform with edge caching.

5. Verify the response contains actual content

A page can return 200 OK with valid HTML and still be functionally empty — an app shell with no rendered content because the JavaScript that populates it never loaded.

What to check:

Look for a stable marker that only appears when the page rendered correctly — a page title, a heading, a product name, a form label, or CTA text:

# Check for expected page title
curl -s https://yoursite.com | grep "<title>Your App Name"

# Check for a content marker that should always exist
curl -s https://yoursite.com | grep "Sign in"

# Check the canonical tag as a secondary signal
curl -s https://yoursite.com | grep 'rel="canonical"'

If the response is just a <div id="app"></div> and some <script> tags with none of your expected markers, your framework didn't render. Don't just check the homepage — verify one or two critical routes (checkout, login, pricing) as well.

When this matters most: Any SPA or SSR framework (Next.js, Nuxt, Gatsby) where the HTML is a shell and JavaScript does the rendering. Also useful for catching branded CDN error pages that return 200 with valid HTML — but not your HTML.

6. Check your critical-path dependencies

Your site is fine. Your payment provider's JS CDN is down. Your checkout is broken and you have no idea.

Not every external script matters. Focus on the ones where failure means broken functionality, not just a missing pixel:

Payment SDK (Stripe, PayPal) — checkout dead
Auth provider (Auth0, Firebase Auth) — login broken
Bot protection (reCAPTCHA, Turnstile) — forms unsubmittable
Feature flags / config endpoint — if your app boot depends on it, it's critical path

What to check:

# Extract external script sources
curl -s https://yoursite.com | grep -oP 'src="https://[^"]*\.js"'

# Verify each critical one responds with correct type
curl -I https://js.stripe.com/v3/

When this matters most: Always. Third-party failures happen independently of your deploys and are outside your control. But they break your users' experience just the same.

7. Compare content fingerprints

The most subtle failures are when your site returns different content than expected — a stale cached version, a CDN error page that returns 200, or content from a completely different environment.

What to check:

# Generate a hash of your page content
curl -s https://yoursite.com | sha256sum

# Compare against a stored baseline
# If the hash changed and you didn't deploy, something is wrong

Store the hash after a known-good deploy and compare on every subsequent check. Update your baseline after intentional deploys — otherwise every deploy looks like a content change. Combine this with the content markers from step 5 to distinguish between "content changed because we deployed" and "content changed because something broke."

When this matters most: Between deploys. If the hash changes and nobody deployed, something is wrong.

A starting point script

Here's a deliberately minimal version. In practice, you'll want route-specific checks, dynamic asset discovery, content markers per route, and multi-region validation. But this covers the basics as a CI post-deploy gate:

#!/bin/bash
SITE="https://yoursite.com"
FAILED=0

echo "Running post-deploy checks for $SITE"

# Check main page responds
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$SITE")
if [ "$STATUS" != "200" ]; then
  echo "FAIL: Main page returned $STATUS"
  FAILED=1
fi

# Check JS bundle MIME type
MIME=$(curl -sI "$SITE/assets/app.js" | grep -i content-type | tr -d '\r')
if [[ "$MIME" != *"javascript"* ]]; then
  echo "FAIL: JS bundle MIME type is $MIME"
  FAILED=1
fi

# Check redirect chain isn't excessive
REDIRECTS=$(curl -sIL "$SITE" | grep -c "HTTP/")
if [ "$REDIRECTS" -gt 4 ]; then
  echo "WARN: $REDIRECTS redirects detected"
fi

# Check for expected content marker
if ! curl -s "$SITE" | grep -q "<title>Your App Name"; then
  echo "FAIL: Expected content marker not found — page may not have rendered"
  FAILED=1
fi

if [ "$FAILED" -eq 0 ]; then
  echo "All checks passed"
else
  echo "Issues detected — investigate before closing the deploy"
  exit 1
fi

The problem with scripts

A shell script is a good start. It catches the obvious stuff on deploy day.

The problem is what happens after deploy day. Scripts run once. They check from one location. They break when your asset paths change. They don't catch the CDN edge that starts serving stale content three hours later, or the third-party SDK that goes down on Tuesday.

Status codes are a terrible proxy for user experience. The real gap isn't "did this deploy work" — it's "is this site still working, right now, from everywhere."

That's what we built Sitewatch for — continuous verification of everything in this checklist, from multiple regions, on every check cycle. Not just after deploys.

What does your post-deploy verification look like? If you've got a check I didn't cover, drop it in the comments — always looking to make the checklist more complete.

The Most Dangerous Response Code Isn't 500. It's 200.

Sitewatch — Thu, 26 Mar 2026 19:26:05 +0000

A 500 error is loud. Your monitoring fires. Your on-call gets paged. Someone fixes it within the hour.

A 200 that serves broken content is silent. Your monitoring dashboard stays green. Your users see a blank page, a broken checkout, a form that submits to nothing. And nobody on your team knows until a customer complains — or churns.

Modern web stacks fail in ways a simple status code cannot describe. Here are six common patterns where 200 OK actively hides broken websites.

1. The Phantom Deploy: Missing Bundle Hashes

Modern frontend frameworks produce hashed filenames: main.a4f2c.js, styles.b7e91.css. On every deploy, these hashes change. The HTML document references the new filenames. The old files get cleaned up.

Here's the failure mode:

You deploy at 2pm. The build produces vendor.c8d13.js and app.7fb2e.css. Your CDN edge nodes in Frankfurt still serve the HTML from the previous build — which references vendor.9a1b0.js and app.3de4f.css. Those files are gone. The document loads fine. Every asset 404s. Users in Europe see a blank screen for 45 minutes until the CDN cache expires.

This is especially common on:

Netlify with atomic deploys but CDN propagation delays
Vercel with ISR pages serving stale HTML
Any CDN where HTML cache TTLs are longer than deploy frequency

The fix is cache invalidation discipline — but the point is that your uptime monitor never sees the problem. It fetches the document, gets 200, and moves on. It never checks whether main.a4f2c.js actually exists.

2. The Silent MIME Rejection

Browsers enforce strict MIME type checking for scripts and stylesheets. If your server responds with Content-Type: text/html for a JavaScript file, the browser silently blocks execution. No visible error. Your SPA just doesn't boot.

How does a JS file end up served as HTML?

A CDN or reverse proxy intercepts the request and returns an error page (HTML) instead of the actual file
A misconfigured Nginx try_files directive falls through to index.html for any path — including .js files
Cloudflare's custom error pages replace a 404 with a branded HTML error page, served as text/html

The server logs show 200. The CDN metrics show successful delivery. The browser silently ignores the script. Your monitoring sees 200 and reports everything healthy. The only way to catch this is to verify the Content-Type header against the expected MIME type for each critical asset.

3. The Redirect Ouroboros

A redirect loop is usually obvious — the browser shows ERR_TOO_MANY_REDIRECTS. But most monitoring tools follow a limited number of redirects and report the final status, some don't follow redirects at all, and the loop might only trigger for specific user agents, cookie states, or geographic regions.

Common causes:

A Shopify app redirects /products to /collections, while a theme redirect sends /collections back to /products
Mixed HTTP/HTTPS configurations where each protocol redirects to the other
CDN-level redirect rules conflicting with origin-level rules

Your monitoring sees the first 301 and considers that a valid response. Meanwhile, real browsers with real cookies hit an infinite loop.

4. The Ghost Server

After a DNS migration, CDN swap, or infrastructure change, your domain might resolve to the wrong server. The wrong server still responds — it's just not your server anymore.

Scenarios:

You migrate from AWS to Vercel but a DNS record still points a subdomain to the old EC2 instance. The instance serves stale content from 6 months ago. 200 OK.
A CDN failover activates and sends traffic to a backup origin that was never updated. It serves the version from the last time someone deployed to it. 200 OK.
A load balancer health check passes because the server responds, but it's responding with a default page, not your application.

The response is valid HTTP. The status is 200. The content is just... wrong. It's from a different version, a different environment, or a different application entirely.

Catching this requires tracking the resolved IP and server identity over time — and comparing the content fingerprint against a known baseline. Not just "did it respond" but "did it respond with the right content from the right server."

5. The API Gateway Mask

API gateways, reverse proxies, and edge functions sit in front of your application. When the app behind them crashes, the gateway often catches the error and returns its own response — with a 200 status code.

Your landing page URL returns {"error":"unauthorized","statusCode":401} as a 200 OK with Content-Type: application/json. Or your edge function crashes and the platform serves a generic fallback page. Valid HTML. 200 OK. Not your application.

Common with AWS API Gateway fronting Lambda, Cloudflare Workers with fallback behavior, and Vercel edge middleware that wraps errors. If your monitoring doesn't verify that the response content type matches what you'd expect for that URL, these failures pass undetected.

6. The Third-Party Collapse

Your site loads. Your HTML is correct. Your own assets are fine. But a critical external dependency is down — and your page breaks without your server knowing.

This matters most when the dependency is load-bearing: Stripe's JS SDK failing means your checkout form renders as an empty div. An auth provider's script timing out means users can't log in. A CDN-hosted app bundle 404ing means your SPA doesn't boot. A bot-protection script blocking form submission means your lead capture is dead.

Your server returns 200. Your monitoring checks your domain. The broken resource is on someone else's domain. That gap is where this failure hides.

The Common Thread

All six patterns share one characteristic: the HTTP status code says everything is fine while the user experience is broken.

Status codes tell you whether a request succeeded at the protocol level, not whether the page is actually usable. A 200 means "the server processed your request and returned a response." It doesn't mean the response contains what the user needs.

A lot of monitoring still relies on a false assumption: that a successful HTTP response is a good proxy for a working site. For simple, server-rendered pages with no external dependencies, that was close enough. For modern web applications with hashed assets, CDN layers, API gateways, SPAs, and third-party dependencies, it's a dangerous gap.

What Would Actually Catch These

The common thread across all six patterns is that the status code is the wrong layer to monitor. Catching these failures means shifting from "did the server respond?" to "does the response actually constitute a working page?"

That means treating the HTML document as a manifest, not a destination — following up on the assets it references, verifying their types, and confirming they load. It means following redirect chains to completion rather than trusting the first hop. It means tracking what your site returns over time so you notice when the content silently changes. And it means checking from more than one location, because CDN failures don't happen everywhere at once.

This is the problem we built Sitewatch to solve. But regardless of what tool you use, the principle matters: stop trusting 200 OK as proof that your site works.

Have you been burned by a silent failure that hid behind 200 OK? I'd be curious to hear what the failure pattern was — these stories are how the industry gets better at catching them.

Your Site Is Up. Your Site Is Broken. Both Are True.

Sitewatch — Thu, 26 Mar 2026 13:52:15 +0000

Every monitoring tool on the market will tell you when your site is down. None of them will tell you when your site returns HTTP 200 OK but serves a broken experience.

We built Sitewatch to close that gap. This post covers the detection engineering behind it — what we check, how we confirm failures, and why traditional uptime monitoring has a fundamental blind spot.

The Problem: 200 OK Is Not "OK"

A standard uptime monitor sends an HTTP request, gets a 200 status code, and marks your site as healthy. But a 200 response tells you almost nothing about whether your site actually works.

Here are real failure patterns that return 200 OK:

A Vercel deploy changes your bundle hash. main.a4f2c.js now 404s, but the HTML document still returns 200. Your app shell loads. Nothing renders.
Cloudflare serves app.js with Content-Type: text/html instead of application/javascript. Chrome silently blocks execution. The page loads — with zero interactivity.
A WordPress plugin misconfigures redirects. /checkout redirects to /checkout redirects to /checkout. The browser gives up. Your uptime tool never follows the chain.
After an AWS migration, your domain resolves to a decommissioned server. It serves stale content from six months ago. HTTP 200. Green dashboard.

Every one of these is invisible to a ping-based monitor. Every one of them is a real incident that affects users.

Our Detection Model: 11 Rules Across 3 Categories

We don't just check "is the server responding." We run 11 detection rules across three domains:

Asset Integrity

This is where most silent failures live.

ASSET_MISSING — We check whether critical JS, CSS, and image assets return valid responses. After a deploy, bundle filenames often change (hashed filenames like main.a4f2c.js). If the HTML references an asset that now 404s, 403s, or 5xxs, the page is broken even though the document loaded fine.

ASSET_MIME_MISMATCH — We verify that the Content-Type header matches what the browser expects. A JavaScript file served as text/html will be silently blocked by the browser's MIME type checking. The page loads. The script never executes. No error in the server logs.

We use HEAD requests to check status codes and MIME types — no browser overhead, no JavaScript execution cost. If HEAD fails or returns ambiguous results, we fall back to GET.

Routing & Resolution

REDIRECT_LOOP — We follow redirect chains and detect circular patterns before ERR_TOO_MANY_REDIRECTS kills the request. We log the full chain with status codes and final destination.

HOST_DRIFT — We track the resolved IP and server headers over time. If your domain suddenly resolves to a different origin — common after DNS migrations, CDN changes, or failover misconfigurations — we flag it and compare the content fingerprint against the known baseline.

NON_HTML_PAGE — If a URL that should serve a web page returns JSON ({"error":"unauthorized"}), XML, or an empty body, we catch it. This happens more than you'd think with API gateways sitting in front of web apps.

Availability & Performance

UNAVAILABLE — The classic check. 5xx responses, timeouts, connection refused. We still do this — it's just not the only thing we do.

Plus broken link checking (up to 50 links per page), API endpoint monitoring, and response structure validation.

Confirmation: The 2-of-3 Retry Model

False positives are the fastest way to lose trust in a monitoring tool. If your team gets woken up at 3am for a transient CDN glitch that resolved itself in 8 seconds, they stop trusting alerts. Then they miss the real ones.

We use a 2-of-3 retry confirmation model:

First check detects an issue.
We immediately re-check twice more.
The issue must fail on at least 2 of 3 consecutive checks to become an incident.

A single transient failure — a momentary CDN hiccup, a network blip, a slow edge propagation — never triggers an alert. This eliminates the noise without adding dangerous delay. The entire confirmation cycle completes within the check interval.

For multi-region checks, this runs independently per region. A CDN edge failure in EU doesn't need to reproduce in US to become an incident — but it does need to reproduce within its own region.

Fingerprinting: One Problem, One Incident

When an asset breaks, every check that hits that asset will detect the same failure. Without deduplication, a broken JS bundle could generate dozens of alerts over a few hours.

We generate a SHA-256 fingerprint for each detected issue — combining the failure type, affected URL, and relevant metadata. If an active incident already exists with the same fingerprint, we don't create a new one. We also enforce a 30-minute per-incident cooldown on alert dispatches.

The result: 12 consecutive checks detecting the same broken asset → 1 alert, not 12.

Root Cause Classification

Detecting a failure is half the problem. The other half is telling you why it broke.

We classify every incident into one of 10 cause families across three domains:

Infrastructure: DNS resolution failure, origin server error, SSL/TLS certificate issue, network connectivity.

Application: Deployment artifact missing, application error, configuration drift.

Content Delivery: CDN cache misconfiguration, third-party dependency failure, redirect misconfiguration.

Classification uses evidence from the check data — HTTP headers, response content, redirect behavior, MIME types, IP resolution, and fingerprint diffs. We assign a confidence score up to 90%. A high-confidence diagnosis (70%+) means the evidence strongly matches a known failure pattern.

Stack-Aware Context

Knowing what broke and why is useful. Knowing how to fix it for your specific stack is what actually saves time.

We detect 23 tech stacks by analyzing HTTP response headers (X-Powered-By, Server, X-Vercel-Id), HTML meta tags, script patterns, and asset URL structures. Detection happens automatically with every check — no configuration required.

When an incident fires, the fix guidance is tailored to your stack. A "deployment artifact missing" incident on Vercel gets different remediation steps than the same failure on Netlify or a self-hosted Nginx setup.

Multi-Region: Catching Regional Divergence

CDN failures are often regional. Your site might work perfectly from US-East while EU users get stale cached assets from a failed purge.

Multi-region checks run the full detection suite from multiple geographic points. Each region runs its own independent 2-of-3 retry confirmation. We compare results across regions to distinguish between:

Global outage — all regions failing
Regional divergence — specific edges serving different content, stale caches, or geo-routing sending traffic to wrong origins

This catches CDN edge divergence, geo-routing misconfigurations, and regional failover failures — problems that are invisible if you only check from one location.

What We Don't Do

We don't run a headless browser. We don't execute JavaScript. We don't render the page and take screenshots.

This is a deliberate choice. Browser-based monitoring is slow, expensive, and fragile. It catches visual regressions — which matters — but it's a different problem from "your assets are broken and your site is non-functional."

Our checks are HTTP-based. They're fast, cheap to run at high frequency, and they catch the structural failures that actually take sites down in production. Visual regression testing is complementary but separate.

The Architecture in Summary

Check cycle:
  1. Fetch document (GET)
  2. Verify status, content-type, body structure
  3. Extract and verify critical assets (HEAD requests)
  4. Follow redirect chains
  5. Compare fingerprints against baseline
  6. Run detection rules (11 rules)
  7. 2-of-3 retry on failures
  8. Classify root cause (10 families, up to 90% confidence)
  9. Match tech stack (23 stacks)
  10. Generate incident with evidence + fix guidance
  11. Deduplicate and dispatch alerts

All of this runs every 5–30 minutes depending on plan, from multiple regions, without requiring any code changes or agent installation on your infrastructure.

Try It

Sitewatch has a free tier — 1 site, 30-minute checks, no credit card. If you manage multiple sites and want to catch the failures your current monitoring misses, that's what we built it for.

getsitewatch.com

If you have questions about the detection approach or want to dig into specific failure patterns, drop a comment — happy to go deeper on any of this.