200 OK: what it means and what it hides

What a 200 guarantees

A 200 is the standard success status. It tells you a narrow and specific set of things: DNS resolved, a TCP connection was made, TLS negotiated if the URL was HTTPS, the server accepted the request line and headers, and it produced a response it considers successful. For a GET the body is the requested resource; for a POST it is the result of the action.

What a 200 does not tell you is whether the page contains the product catalog, whether the checkout form rendered, whether the JavaScript that fills the page received its data, or whether the response you got is the one your visitors in another country are getting. All of that lives in the body, and the status code never looks at the body.

The 200 that is really a failure

Status-code monitoring on its own is not enough, because a broken site answers 200 in all of these cases:

• A maintenance page. Deliberately served at 200 by a deployment script or a CDN rule. Uptime looks perfect for the whole outage window.
• A caught application exception. The framework traps the error and renders a friendly "something went wrong" page through the normal template pipeline, which sets the default status of 200.
• A soft 404. A "page not found" message returned at 200 instead of 404. Visitors are confused and search engines may keep the URL indexed or treat the whole pattern as low quality.
• An empty client-rendered shell. The HTML document loads fine, but the API call that fills it failed. The status is 200 and the page is blank.
• A stale or wrong-language cached copy. An edge node whose origin fetch failed keeps serving what it already has, at 200.
• A parked or hijacked domain. After a DNS change it answers 200 with someone else's content.

A slow 200 is still a problem

Response time often matters more than the code. A page that takes twelve seconds to return 200 is functionally down for most visitors, who will have left before it finishes. The status code has no time dimension at all, so you have to measure response time and threshold it separately. Size is worth watching for the same reason: a 200 that returns 300 bytes where it normally returns 80 KB is a strong signal that the page rendered without its content.

How to verify a 200 is a real success

1. Read the status line and the timing together:

   curl -sI -o /dev/null -w "%{http_code} in %{time_total}s\n" https://example.com/

2. Fetch the body and assert on a string that only appears when the page is genuinely working, such as a heading, a price or a footer marker, rather than on something the error template contains too.
3. Assert on absence as well as presence. Searching for phrases such as "under maintenance", "temporarily unavailable" or your framework's exception wording catches the friendly-error case.
4. Compare response size against a known-good baseline. A sudden collapse in body length usually means the shell rendered and the content did not.
5. Check a deep page, not only the home page. Home pages are the most heavily cached and the most likely to keep answering 200 while the application behind them is broken.
6. Repeat from more than one network. A 200 from your office and an error from another continent points at DNS, CDN or geographic routing rather than the application itself.

What a green uptime check can miss

A monitor that reads only the status code will report a green site through an entire incident that started with a maintenance page nobody removed. Pairing the status check with a keyword assertion and a response-time threshold is what turns "the server answered" into "the page worked". HostTracker offers 13 monitor types and alerts by email, SMS, voice call, Slack, Telegram and more, so a content mismatch raises the same alert an outage would. Run a URL through the HTTP check tool to see its status, headers and timing, or read the 2xx family and 500 Internal Server Error for the responses a friendly error page is hiding.