Your website returns 200 OK. Why can customers still be unable to use it?

Start with the action that matters

A 200 response says that the server successfully handled that HTTP request. It does not establish that a customer can sign in, retrieve an order or finish a checkout. A CDN can serve an old homepage while the application behind it has lost its database connection. A single-page application can return its HTML shell while every API request fails.

Pick one important customer action and write down the dependencies it needs. For an order lookup, these might be DNS resolution, a valid TLS connection, the application process, authentication and a readable database. A homepage monitor observes only part of that chain. Give each check a name that states what it proves: “Homepage HTML” is more precise than “Everything healthy.”

Use three independent assertions

Start with an expected status, a stable piece of response content and a latency threshold. A health endpoint might return 200 with a small JSON document containing a readiness flag. Keep that endpoint inexpensive and omit private database names, stack traces and credentials. Use a restricted monitoring account when a check genuinely needs authentication.

• A status assertion catches an explicit server error or an unexpected redirect to a login screen.
• A content assertion catches an error template returned with 200 or a missing expected JSON value.
• A latency threshold catches requests that eventually succeed but take too long for the intended use.

Avoid asserting a timestamp, advertising copy or another value that changes on every request. An assertion should describe stable behaviour, not yesterday's page rendering. Inspect your endpoint first with the HTTP status checker and response time checker.

Keep the check safe to repeat

A monitoring request can run thousands of times per day. Do not point a repeated POST request at a real purchase or deletion endpoint. Use read-only operations, a dedicated test account and a bounded response size. For an authenticated API sequence, arrange test data that can be read repeatedly without creating business transactions. Treat authentication secrets as credentials and rotate them when access changes.

Separate application failures from observation failures

A timeout alone does not identify the faulty component. Preserve the observation time, probe, resolved destination, response code and available timing phases. If DNS resolution fails, increasing the expected HTTP timeout will not repair DNS. If the response is a cache hit, a successful observation may say more about the edge than the origin.

UptimeMonitor360 supports HTTP assertions and API transaction checks. Browser checks require separately provisioned capacity; they are not included in the initial public deployment. Read the incident confirmation guide before choosing how many failures should trigger an alert.

Verify the monitor after a deployment

Change a safe assertion in a test monitor so that it deliberately fails, confirm that the incident and notification arrive, then restore it. A green chart without a tested notification path is incomplete operational evidence. Record what the monitor covers and what still requires a different check.