HTTP status checker
One GET from our servers: the status code you actually return, how long it took, how many redirects were on the way, and the certificate at the end of them.
The check runs from our servers and needs JavaScript. Everything below works without it.
Free plan, ten checks, no card. This page checks once; an account checks on a schedule and tells you when it changes.
"It opens for me" is not a status check
Your browser is the worst possible instrument for this. It has your cookies, your DNS cache, a warm connection to the CDN edge nearest you, and it silently follows every redirect without telling you there were four. A check from outside, with none of that, answers a different and more useful question: what does an anonymous client on someone else's network get?
The redirect count is worth a look every time. Each hop is a
full round trip before anything renders, and chains grow by
accident —
http → https → www → trailing slash
is four requests to serve one page. The final URL in the
result is where you actually ended up, which is not always
where you thought you were pointing.
Codes that surprise people
| Code | What it usually means |
|---|---|
200 | the answer everyone expects |
301 / 308 | permanent redirect — fine, but every hop costs the visitor a round trip |
302 / 307 | temporary redirect; a surprising number of them are permanent in practice |
403 | reachable, and refusing you — often a WAF or a country block, not a bug |
404 | the URL you are monitoring moved and nobody updated the check |
429 | you are being rate limited, which a naive uptime check reads as an outage |
500 / 502 / 503 | the classic outage trio: app crash, bad gateway, overloaded or restarting |
A monitoring check that only asks "is the code 200?" will page you for a 429 and stay quiet through a 200 that renders an error message. That is why real checks also look at the body — see keyword checks.
What this page cannot tell you
It is one request, from one place, at one moment. That answers "is it broken right now" and nothing else. The failures that actually cost money look healthy from a single probe: one bad node out of four behind a load balancer, a regional routing problem, a certificate that expires at 3 a.m. on Sunday, a slow leak from 200 ms to 2 s over a week.
Those are found by checking on a schedule, from more than one place, and comparing over time. An HTTP check runs from several regions, confirms an outage from a second region before alerting (so one flaky vantage point does not wake you), and watches status codes, response time, keywords and certificate expiry together.
Questions
What does this actually do?
One GET request from our servers to the URL you enter, with a 7-second timeout and up to three redirects followed. It reports the final status code, how long the whole chain took, how many redirects it went through, the final URL, and — for https — the certificate and TLS version.
Why does the response time differ from my browser?
Because this is one request from one place, measuring the time to a response, not a full page load. Your browser also fetches CSS, scripts and images, runs them, and does it from your network rather than ours. Treat the number as a signal about the server, not as a page-speed score.
Can I check a page behind a login or on a custom port?
No. The tool sends no credentials and only speaks to ports 80 and 443 on public hosts — private addresses, localhost and cloud metadata endpoints are refused. Anything more than that turns a free public form into a port scanner pointed at other people networks.
It says my site is fine, but users report it is down.
One check from one location and one moment says very little. Intermittent failures, a single bad node behind a load balancer, or a regional routing problem all look healthy from here. That is exactly the difference between a one-off check and monitoring from several regions on a schedule.
Related
Checking a certificate rather than a page? The SSL certificate checker shows issuer, expiry and TLS version. Working on a schedule instead? The cron expression tester shows when an expression fires. Both are on the tools page.