Site Returns 200 OK but Shows an Error

It's one of the most frustrating web monitoring traps: your monitoring tool indicates "UP" and "200 OK", but your users see a blank page, an error message, or incorrect content. The HTTP server considers it responded successfully, even if what it served is unusable.

This problem occurs because HTTP codes describe the success of transmission, not the validity of business content. A nicely displayed PHP error page, a maintenance page, or even a completely empty page can all return a 200 code. Classic HTTP monitoring is blind to these situations.

The solution is content verification: instead of only checking the HTTP code, you also verify that critical elements are present in the response. MoniTao makes it easy to configure this verification to detect invisible broken pages.

Symptoms of a failing 200 page

Here are the signs that your site returns 200 but has a problem:

• Green monitoring, unhappy users: your dashboard says "UP" but support receives complaints. The gap between what monitoring sees and what users experience is an alarm signal.
• Blank page or error message: the browser displays an empty page, a "Database connection error" message, or a maintenance page when the site should be working.
• Critical functionality missing: the "Add to cart" button has disappeared, the login form no longer displays, images don't load. The 200 code hides an application problem.
• Outdated or incorrect content: the CDN serves an expired cached version, or the wrong language displays. The page "works" but not correctly.

Common causes of the 200-but-error problem

Several situations can cause this gap between HTTP code and actual content:

• Application error with styled error page: the application catches the error and displays a nice "An error occurred" page instead of letting the server return a 500. Good for UX, bad for monitoring.
• Database inaccessible: the web server works but MySQL/PostgreSQL is down. The application displays "Connection error" with a 200 because technically it responded.
• Corrupted or stale CDN cache: Cloudflare, Fastly or your CDN serves a cached version that's no longer valid. The origin might even be down, but the CDN responds 200 with stale content.
• Client-side JavaScript error: the HTML loads (200) but a JS error prevents rendering of critical components. Server-side monitoring doesn't see client-side errors.

Diagnosing the problem

Identifying and fixing these situations invisible to classic monitoring:

• Identify critical elements: list what MUST be present on each critical page: logo, footer text, CTA button, form. If these elements disappear, the page is broken even with a 200.
• Compare current response vs. expected: curl the page and compare with a working version. Look for size differences, missing elements, error messages.
• Test in real conditions: does monitoring see the same thing as users? Check headers, cookies, user-agent. A site can work for bots but not for humans.
• Check application logs: even if the HTTP code is 200, logs can reveal internal errors that were caught and hidden by a "clean" error page.

Content verification configuration example

Here's how to verify that expected content is present on your page:

# With curl - verify text is present
curl -s https://example.com | grep -q "Add to cart" && echo "OK" || echo "FAIL"

# Verify minimum response size
SIZE=$(curl -s https://example.com | wc -c)
[ $SIZE -gt 1000 ] && echo "OK: $SIZE bytes" || echo "FAIL: page too small"

# Basic monitoring script
#!/bin/bash
RESPONSE=$(curl -s https://example.com)

if echo "$RESPONSE" | grep -q "My Site"; then
    echo "Content check: PASS"
else
    echo "Content check: FAIL - keyword missing"
    # Send alert
fi

These examples show the basic principle. MoniTao automates this verification with a simple interface: configure the text to search for, and receive an alert if the text disappears.

Automatic detection with MoniTao

MoniTao goes beyond simple HTTP code to detect real outages:

• Content verification: configure a keyword or phrase that must be present on the page. If the text disappears (blank page, error, different content), MoniTao alerts you even if the code is 200.
• Minimum response size: detect empty or abnormally small pages. A 50-byte page when it usually is 50 KB clearly indicates a problem.
• Snapshot comparison: identify major content changes by comparing successive responses. Useful for detecting defacements or corrupted caches.
• Multi-condition alerts: combine HTTP code + content verification + response time for complete anomaly detection.

Frequently asked questions

Beyond the HTTP code

HTTP code 200 means "successful transmission", not "functional page". This distinction is crucial for effective monitoring. Without content verification, you can have a broken site for hours with monitoring indicating "all good".

MoniTao lets you easily configure content verifications to detect these invisible outages. Identify your critical pages, choose the elements to monitor, and sleep soundly knowing you'll be alerted if something important disappears.

Ready to Sleep Soundly?

Start free, no credit card required.

Create My Account See pricing