HTTP monitor

Check any URL for availability, response time and status code, with control over method, headers, body, redirects and timeout.

Last updated August 5, 2026

The HTTP monitor is the check most status page services are built on. It sends a request to a URL on your interval and records whether the response was acceptable and how long it took.

What each check records

Status — up or down.
Status code — the code the server returned.
Latency — total round trip in milliseconds: DNS, TCP, TLS, time to first byte and body.

That is what is stored. Response bodies and response headers are not retained, so there is no body archive to search after the fact.

Configuration

Option	Notes
URL	Full URL including scheme.
Method	`GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `HEAD` or `OPTIONS`. Defaults to `GET`.
Expected status codes	A list of codes that count as `up`. Leave empty for the default: any 2xx.
Request headers	Arbitrary key/value pairs, e.g. `Authorization: Bearer …`.
Request body	Sent only on `POST`, `PUT` and `PATCH`. Ignored on other methods.
Follow redirects	On by default. Turn it off to assert on the 3xx itself.
Timeout	Total request budget. Defaults to 10 seconds.
Interval	How often to check. Your plan sets the floor — 3 min on Free, 60 sec on Starter, 30 sec on Growth and Scale.

Checks identify themselves with the user agent StatusOwl-Monitor/1.0 (+https://statusowl.net/). Allowlist it if your WAF is strict.

The timeout is split internally into phase budgets — connect is capped so a DNS or TLS stall surfaces as a connect timeout rather than being swallowed into a generic one. The failure reason is recorded with the result.

Expected status codes are exact, not ranges

The expected-status-codes list is a set of exact codes, so a monitor that should accept both 200 and 301 needs both listed. Leaving the list empty means "any 2xx", which is what most monitors want.

What is not supported

Keyword and response-body assertions do not exist. There is no "body must contain" or "body must not contain" check. A monitor's verdict comes from the status code and whether the request completed within the timeout — nothing else. If you need content assertions, expose a health endpoint that returns a non-2xx code when the thing you care about is wrong, and point the monitor at that.

There is also no browser-based or synthetic transaction checking, no JavaScript execution and no multi-step flows.

Practical patterns

Health endpoints over homepages. GET /healthz that returns 200 only when your dependencies are reachable tells you more than a 200 from a cached homepage, and it costs your origin far less.

HEAD for heavy pages. The status code and TLS handshake are still validated, but the body is not downloaded — the response-time graph then measures your server rather than your page weight.

Authenticated checks. Put a long-lived read-only token in a request header rather than exposing an unauthenticated endpoint. Headers are stored with the monitor; treat that token as you would any other stored credential and scope it to nothing but the health check.

Regions

Every monitor runs from one region. Multi-region checking is built but capped at one region per monitor on every plan — see Monitoring regions for the honest version.

After a failure

Three consecutive failed checks on a monitor attached to a status page opens an incident on that page, if the page has automatic incidents turned on. See Automatic incidents.

A failing check does not send a notification. See Notifications overview.