Website & HTTP monitoring
Check that a URL is up and fast, from the edge.
What it watches
An HTTP monitor asks for your URL from the edge on your interval and reads the whole response, not just whether the connection opened. That distinction is the point: a 200 that took four seconds and a 200 that took forty milliseconds are not the same event, and only one of them is worth waking up for.
So every check lands in one of three states, up, slow, or down, rather than the binary that most tools stop at. Slow is a state of its own, not a flavour of up.
Know which part got slower
A check that reads the body splits its time three ways: DNS and connect, waiting for the first byte, and transferring the rest.
The split is what turns "the site feels slow" into a direction to look. Connect climbing is a network or DNS story. Waiting climbing while connect holds steady is your backend thinking. Transfer climbing is a payload that grew. A single response-time number tells you none of that.
Connection timing needs a response to time, so it appears on checks that fetch the body. A HEAD check, the default, reports total latency only.
A 200 that renders nothing still fails
Status codes lie. A deploy that ships an empty shell, an error page served cheerfully as 200, a JSON endpoint that quietly starts answering null: to the status line, all of it is fine.
Content rules let the check assert on the response body, so a page that returns 200 and renders nothing is down, which is what your users would call it.
Alerts when the state changes, not every minute
A monitor that pages you every minute for an hour is a monitor you mute, and a muted monitor is worse than no monitor. UpCheck alerts on the transition: once when it breaks, once when it recovers.
A confirmation streak sits in front of that, so a single blip that fixes itself on the next check never reaches you at all.
Point it at a URL
An HTTP monitor needs nothing but the URL. HEAD is the default method, since most endpoints answer it and it costs your server the least; switch to GET when you need the body, which content rules do.
Create one from the dashboard, or over the API with a project key. Everything the dashboard does, the API does:
curl -X POST https://upcheck-api-a.rekwiem.com/v1/monitors \
-H "Authorization: Bearer upk_your_key" \
-H "Content-Type: application/json" \
-d '{ "url": "https://example.com", "interval_sec": 300 }'Create returns the monitor including the result of its first check, so you know straight away whether you pointed it at the right thing. Every field except url is optional and takes the default in the table above.
Tune it when the defaults aren't right
Highlighted is the default.
Build trust with
public status pages.
Every monitor can back a public status page, so the people asking whether you're down can answer it themselves. Ninety days of history per monitor, on your own domain.
Every outage,
written down as it happens.
A failed check opens an incident on its own, and it keeps a timeline: when it broke, what we saw, when it recovered. Nobody has to remember to write the post-mortem's first half.
Planned downtime
shouldn't page anyone.
Schedule a window and the checks keep running, but the alerts stay quiet and the uptime maths doesn't count it against you. One-off or recurring, per monitor.