Website Ping — Is This Site Actually Up?
Test a site the way a browser does — DNS, TCP, TLS and a real HTTP request — so a site that blocks ping still shows up as reachable.
Pingr needs a quick check that you are a person before running more tests. This usually resolves by itself.
Why pinging a website is usually the wrong test
“Ping the site and see if it’s up” is advice from an era when servers answered ping. Today a very large share of the web sits behind a CDN or a cloud load balancer that drops ICMP by default, so pinging a perfectly healthy site returns nothing at all. Tools that call that “down” are wrong about a substantial fraction of the internet, and they send people looking for outages that do not exist.
This tool tests what a browser actually does. ICMP still runs, because it is interesting, but its result is labelled informational and is structurally incapable of changing the verdict.
The layers, and what a failure at each one means
DNS — turning the name into an address. A failure here means the domain does not resolve: it has expired, the nameservers are broken, or the record was never created. Nothing else can work until this does.
Ping (ICMP) — informational only. A cross here means the host does not answer echo requests. That is a configuration choice, not a fault, and it is the entire reason this page exists.
TCP — opening a connection on port 443 (or 80). This is the first result that genuinely matters. If TCP fails, nothing is accepting connections: the server is down, the DNS record points somewhere that no longer serves, or a firewall is dropping traffic from outside. A working website has to accept TCP.
TLS — the encrypted handshake, for HTTPS. A failure here means the machine is up and listening but the certificate or the TLS configuration is wrong. This is worth separating from an outage, because visitors will see a full-page browser warning, and in practice most of them will leave rather than click through — which is worse for you than a clean outage. Expired certificates, a certificate that does not cover the hostname, and a missing intermediate chain are the three usual causes.
HTTP — the actual request. The status code tells you what the application did: 200 is fine, 301 and 302 are redirects that Pingr follows, 404 means the site is up and that specific path is not there, and 5xx means the web server is running and something behind it is broken. A 5xx is an application problem, not a network problem, and there is nothing to fix from this side.
Redirects
Most sites redirect: http:// to https://, or the bare domain to www. Pingr follows up to three hops and shows the full chain with each status code, so you can see whether a redirect loop or an unexpected destination is the problem. Every hop is re-resolved and re-checked before it is followed, and a redirect that points at a private address is refused rather than followed.
What Pingr sends
One GET request. No cookies, no authentication, no request body, no custom headers. It reads at most 32 KB of the response and then closes the connection. Requests identify themselves as PingrBot/1.0 (+https://pingr.com/about), so if you find one in your logs you can see exactly what it was and get in touch.
If the site works for you but not here
The most common explanation is geography. Pingr tests from one fixed location, and a site can be blocked by region, served differently by country, or resolve to different addresses depending on where the question is asked from. A firewall that allows your office and nothing else looks identical, from here, to a site that is down. If the TCP layer fails but you can load the page, test the port directly — the difference between a refused and a silently dropped connection tells you which of the two it is.