An availability check limited to the HTTP status code can report a website as operational while visitors see an error page, a maintenance screen or empty content. To reduce these false positives, also check for a characteristic element of the expected page.
What HTTP 200 really means
When a server returns 200 OK, it indicates to have successfully processed the request. This status describes the HTTP exchange, not the functional quality of the content received.
The distinction matters: the reverse proxy can answer, the TLS certificate can be valid and the page can be downloaded, while the application behind it is failing.
Situations that create a false positive
Several failures can still return an HTTP 200 response:
- a custom error page is returned with a wrong HTTP code;
- a maintenance screen temporarily replaces the home page;
- the application loads its structure but not its main data;
- a cache or CDN serves an obsolete backup page;
- a redirect leads to a generic page that responds correctly;
- the domain points to the wrong site, itself perfectly accessible.
In each of these cases, the probe sees a valid response while the user does not find the expected service.
Complete control with expected content
The principle is to choose a short and stable text that must appear on the home page: the name of the service, a title or an expression specific to the site.
The check then has two levels:
| Monitoring | What it confirms | Limit |
|---|---|---|
| HTTP code | The server responds without an HTTP error | The wrong page can return 200 |
| Expected content | The response contains a page-specific marker | The marker must remain stable |
| Functional path | A complete action really works | More complex and fragile to maintain |
For simple monitoring, the first two levels already cover many incidents without requiring a full navigation scenario.
How to choose a good reference text
The expected content must be specific enough not to appear on a generic error page, but stable enough not to change with each update.
- prefer the service name or the page’s main title;
- avoid a date, counter or temporary promotional message;
- use no personal or confidential information;
- use short, readable text that is easy to maintain;
- update the control when the page is voluntarily renamed.
For example, a site called "Atelier Horizon" can search for this name rather than a current phrase displayed only for a few days.
Why confirm failure before alerting
A single absence of text can be caused by a brief deployment, network delay or incomplete response. Immediately triggering an alert creates noise and reduces confidence in monitoring.
A reasonable strategy is to record the first failure and then confirm the incident in the next check. An alert is sent only if the anomaly persists. The return of the expected content then allows the monitor to report recovery.
Check beyond the HTTP status code
TechAtelier Protect can monitor the external availability of a domain and check for expected text on its home page. The goal is to detect an incorrect page even when the server returns HTTP 200.
Create a Protect accountWhat this check does not replace
The presence of text does not guarantee that all the functions of the site are available. A form, login, payment or search feature may fail regardless of the home page.
Content control is therefore a good intermediate level: more reliable than a simple HTTP test, but lighter than an automated user path. Critical services can complement this with application health endpoints and targeted functional testing.
For an understanding of incident confirmation and recovery follow-up, see also the guide Why monitor your site from outside?.
To determine the order of intervention when a check fails, see also how to prioritize a domain alert.
Published on 12 August 2026.