Why Can a Website Return HTTP 200 but Still Be Broken?

Check what the response says

A maintenance page, a cached error screen or a health endpoint with a failed database can return HTTP 200. A status-only monitor can therefore report success while users see a failure.

Use a keyword check for stable content

Choose a phrase that is present in a working response and absent in the failure you care about. Statance keyword checks are case-insensitive. “Contains” fails when expected text is missing; “absent” fails when forbidden text appears.

Use a response you control, not a fragile phrase that changes with translations or marketing copy. Statance inspects the returned body; it does not execute JavaScript to render the page.

Use JSON to check a dependency

For this response, set a JSON monitor path to dependencies.database and the expected value to up. The response fails the assertion even if its HTTP status is 200. A missing path or invalid JSON also fails. Statance compares a configured expected value by its string representation; this is not a general JSON Schema validator.

Use an expected HTTP status such as 200-299 when appropriate. The current default accepted range is 200-399; configure it deliberately rather than assuming every 3xx response represents a healthy application.

Keep health endpoints safe

Return a small, useful readiness signal. Do not expose credentials, database contents, private customer information or stack traces. Verify the application actually checks its dependencies rather than returning a hard-coded success response.

When you need a real browser

A login or checkout journey can fail after the HTML loads. HTTP, keyword and JSON checks cannot prove that a multi-step browser workflow works. Statance currently provides response checks, not Playwright browser journeys. Use browser synthetic testing alongside it when that is required.

Configure API monitoring, configure keyword checks, or choose a check interval.