Monitoring

Website Monitoring

Website checks run from outside your infrastructure. Each check requests the page and verifies the status code, the response time and, optionally, text that must appear on the page.

Why a 200 status is not enough

A site can return HTTP 200 while showing a database error, a blank page or an empty template. A check that only looks at the status code reports all of these as up.

Adding a short phrase that only appears on a working page, such as a product name or a heading, confirms that the application works, not just the web server.

A request and the three things checked in the responsethe checkyour sitestatus coderesponse timeexpected text

Checks from outside your network

An agent on your server cannot report that the server itself is down or unreachable, and that is the outage that matters most.

Checks run from the platform over the public internet, the same way visitors reach you. They test the whole path: DNS, network, web server and application.

Incidents for every outage

When a check fails, the platform opens an incident that records when the outage started, what the check saw and when the site recovered.

You get a precise record, such as a six-minute outage with a 502 response and its start time, instead of knowing only that the site was down at some point.

A row of check results with a short outage, recorded as an incidentincident · 5 minutesevery check, kept

Choosing a page to monitor

The home page is often heavily cached, so it can load normally while the rest of the site is broken.

A page that queries the database is a better choice. A dedicated health endpoint that checks its own dependencies and returns an error when they fail is better still.

Best practices

Choose a phrase that disappears when the site breaks. Navigation text such as "Home" also appears on error pages. Content loaded from the database does not.

Do not monitor pages behind a login. The check has no session, so it will always fail.

Watch response times, not only failures. A page that slows from 200 ms to 4 seconds has not failed yet, but it needs attention.

Frequently asked questions

What does a website check look at?
The HTTP status code against an expected range, the response time and, optionally, a phrase that must appear in the response body.
Where do checks run from?
From the platform, over the public internet. An agent on your server could not report an outage that takes the server offline.
How often does it check?
You set the interval per monitor, from every minute upwards. The timeout is kept well below the interval, so a slow response never overlaps the next check.
Can I monitor a site on a server I have not connected?
Yes. A website or API monitor only needs a public address. Connecting the server as well lets Auto-Fix attempt a repair when a check fails.
Does it follow redirects?
No. A redirect is reported as the response, so a site that starts redirecting somewhere unexpected is not hidden.

Key points

  • Status code, response time and page content
  • Checks run from outside your network
  • Outages recorded as incidents
  • Any public URL, whether or not its server is connected
  • Redirects reported, not followed

Related features