Is the website down, or is it just you?
Type a URL and our server sends a single GET request to it, follows any redirects, and reports the HTTP status code it got back along with how long the whole thing took. If the code matches the one you expect and the response arrives within your time limit, the check passes. If the code is wrong, it fails. If the code is fine but the site took longer than your limit, you get a warning: the site is up, just sluggish.
The request comes from our servers in a data center, not from your browser. That matters more than it sounds. Your browser may be serving a cached copy, your office network may route around a broken CDN node, and your ISP's DNS may still remember an old IP address. An outside check sidesteps all of that, so if it fails while the page loads fine for you, the problem is real for at least part of the internet.
Reading the result
The status code tells most of the story:
- 200 means the server answered normally.
- 301 / 302 shouldn't show up as a final result, since redirects are followed. If you see one anyway, the redirect chain is too long or loops back on itself, which is worth fixing on its own.
- 403 often means a firewall or bot protection (Cloudflare, a WAF rule) decided our request looked automated.
- 404 means the server is alive but that page isn't there.
- 500, 502, 503, 504 point to trouble behind the web server: the application crashed, the upstream timed out, or the site is in maintenance mode.
If there is no code at all, the request never got an answer. Typical messages are a DNS error (the domain doesn't resolve), "connection refused" (nothing is listening on the port), or a timeout.
The details block lists curl's timings in microseconds: DNS lookup, TCP connect, TLS handshake, time to first byte. When a site is slow, these numbers usually say where the time went. A slow TLS handshake and a slow first byte are very different problems: one is the network or certificate setup, the other is the application thinking too long.
Expected status code and response time
Most pages should return 200, so that's the default. Change it when you're checking something that intentionally answers differently, such as a health-check endpoint that returns 204, or an old URL that should keep returning 410.
The response time limit defaults to 500 ms. That's a reasonable bar for a normal page served from a nearby region; an API behind a slow database might need more. The maximum you can set is 10 seconds.
One check is a snapshot
A single request tells you how the site behaved at that particular second. Outages rarely announce themselves while you're looking. They happen at 3 a.m., last twelve minutes, and leave nothing behind but a confused support ticket. An HTTP monitor sends the same request every minute and notifies you by email, SMS, a phone call, Telegram, Slack, Pushover or webhook as soon as it fails.