For a lot of teams, website monitoring starts and ends with one simple idea: if the server responds with 200 OK, the site is up.
That sounds reasonable. It is also wrong.
A website can return a perfectly valid HTTP 200 response while the experience is still broken for real users. The homepage may load, but the login form may fail. The product page may render, but the add-to-cart button may do nothing. A WordPress site may return 200 while showing a fatal error message or even a blank white screen.
From the browser’s perspective, the server answered. From the customer’s perspective, the site is broken.
That gap is exactly why basic uptime checks are not enough anymore.
What 200 OK actually means
The HTTP status code 200 OK only tells you that the server successfully returned a response to the request. It does not tell you whether:
- the page content is correct
- the checkout works
- the login flow works
- the page is usable
- the expected data is present
- the JavaScript loaded correctly
- the backend dependencies are healthy
In other words, 200 OK confirms that something came back. It does not confirm that your site is functioning the way users expect.
The most common ways a site can be “up” but still broken
1. Error pages that still return 200
Many sites display application-level errors without returning an HTTP error code. You might see messages like:
- “Something went wrong”
- “Service temporarily unavailable”
- “Error establishing a database connection”
- a custom maintenance message
Technically, the web server delivered a page, so the check sees 200 OK. But the user sees a failure.
2. Blank or half-rendered pages
Modern sites rely heavily on JavaScript. If a critical script fails to load, the browser may receive a valid HTML shell and a 200 status code, but the page itself stays blank, incomplete, or unusable.
This is especially common with single-page apps, dashboards, and sites that depend on third-party scripts.
3. Forms and buttons that don’t work
A contact page can load fine while the form submission endpoint is broken. A SaaS landing page can look healthy while the signup flow fails. An ecommerce store can show products while checkout or add-to-cart is broken.
Again, the page returns 200. The business function does not.
4. “Healthy” APIs with broken data
API endpoints can return 200 with missing fields, invalid JSON values, stale data, or internal dependency failures hidden inside the payload.
For example, an endpoint might respond with a 200 status but include a body showing that the database is disconnected, the queue is stalled, or a downstream service is unavailable.
If your monitoring only checks the status code, you will miss all of that.
5. Slow pages that drive users away
A page can return 200 and still be a problem if it takes too long to become usable. In practice, users do not care whether your server eventually answered. They care whether the page loaded fast enough to use.
That means performance degradation can be just as damaging as downtime, especially for checkout flows, lead forms, and mobile traffic.
Real-world examples
WordPress
A WordPress homepage may return 200 while showing a database connection error, a PHP parse error, maintenance mode, or the classic white screen of death. A simple uptime check often misses the difference between “page responded” and “site is actually usable.”
Shopify
A Shopify store may load the homepage successfully, but a theme issue, app conflict, popup, or third-party script can break product selection, cart behavior, or checkout handoff. The storefront is technically online, but revenue is blocked.
SaaS apps
Your login page may return 200 while authentication is failing behind the scenes. Your dashboard shell may load, but the API calls that populate customer data may be returning broken responses or timing out.
Why basic uptime checks still matter, but are not enough
Basic uptime checks are still useful. They are fast, cheap, and great for catching hard failures like:
- server outages
- DNS failures
- connection refusals
- HTTP 500 errors
- certificate problems
But they only tell part of the story.
If your website matters to sales, support, lead generation, or customer trust, you also need checks that validate what the user actually sees and what the application is actually doing.
What to monitor instead of just status codes
Keyword validation
A simple improvement is to check whether the response body contains text that should be present, or text that must not appear.
For example, you can alert if:
- the homepage no longer contains your expected headline
- the page contains “maintenance mode”
- the page contains “database error”
- a required element is missing from the response
This catches many soft failures that plain status-code checks miss.
API assertions
For APIs, you should validate more than the HTTP code. Check the actual response structure and values.
Useful assertions include:
- expected status code
- required headers
- specific JSON fields and values
- regex matches in the body
This helps detect partial failures early, before they become visible to customers.
Browser-based monitoring
Real browser checks go much further. Instead of asking “did the server respond?”, they ask “did the page actually load and work in a browser?”
Browser monitoring can verify things like:
- page rendering
- login flows
- button clicks
- form submission
- checkout handoff
- visibility of important elements
- redirect behavior
This is the difference between server availability and user experience validation.
Performance monitoring
You should also track response time and page performance, not just availability. A site that is technically up but painfully slow can still hurt conversions, frustrate users, and generate support noise.
Monitoring metrics like Time to First Byte and real page-load timing helps you catch degradations before they turn into revenue problems.
The business cost of trusting 200 OK
When teams rely only on status-code checks, they often discover issues too late. The first alert comes from a customer, a colleague, or a sales team member asking why the form is broken or why the checkout stopped working.
By then, the damage is already happening:
- lost leads
- lost orders
- missed signups
- support tickets
- brand damage
- late-night fire drills
The problem is not that the site was completely down. The problem is that your monitoring gave you false confidence.
A better monitoring approach
A reliable setup usually combines several layers:
- Basic uptime checks to catch hard failures
- Keyword or content validation to detect soft failures
- API assertions to verify application health
- Browser monitoring to test real user flows
- Performance tracking to catch slowdowns before they become incidents
- SSL, DNS, and cron monitoring to cover the silent failures around the site
That is how you move from “the server answered” to “the site is actually working.”
Final thoughts
200 OK is useful, but it is not proof that your website works.
It only proves that a server returned a response. That is a much lower bar than most teams realize.
If your website plays any meaningful role in your business, your monitoring should validate more than availability. It should validate content, functionality, user journeys, and performance too.
Because from the user’s perspective, a broken site that returns 200 is still broken.
