Pinging a website tests something else entirely
Ping sends an ICMP echo request and waits for an echo reply. ICMP has no concept of a port, which means ping never speaks to your web server, never negotiates TLS, and never asks for a page. It asks one question: is there a network stack at this address that is willing to answer.
That question is worth asking. It is just not the question anybody means when they say "the site is down", and the gap between the two produces a specific kind of wasted afternoon.
What a reply proves
Three things, and they are all below the layer where websites live. Something at that IP address is powered on and connected. Its network stack is configured. The path between you and it carries packets, and here is how long that took.
Everything above that is untested. The web server may be stopped. The application pool may have crashed. The database may be refusing connections, the disk may be full, the certificate may have expired six days ago. A machine in every one of those states answers ping instantly and cheerfully, because answering ping is handled by the kernel and requires nothing else on the box to be working.
Four ways it disagrees with the browser
| Situation | Ping says | Browser says |
|---|---|---|
| Web server stopped, machine up | Replies normally | Connection refused, or a gateway error |
| ICMP filtered at the firewall or in a cloud security group | 100% loss | Site loads perfectly |
| Domain behind a CDN or reverse proxy | Replies from an edge node | Depends entirely on the origin, which was not tested |
| Address families disagree | Replies over IPv4 | Tries IPv6 first and hangs |
The second row is the one that causes the most unnecessary escalation. Blocking inbound ICMP is a default in several cloud environments and a deliberate hardening choice in many others. A host that does not answer ping is not evidence of anything at all, and a monitoring check built on ping alone will page you the day a client's provider changes a firewall default.
The third row is subtler and now applies to most sites worth monitoring. When a domain sits behind a proxy network, the address in DNS belongs to the proxy. Ping it and you get a reply from whichever edge location is nearest to you, with a round-trip time that measures your distance to that node and says nothing whatsoever about the origin server. The origin can be off. The ping is still fast, and it is still green on your dashboard.
The fourth row produces two colleagues who disagree and are both right. If the name has both an A and an AAAA record, ping on most systems picks one family and the browser may pick the other. When the AAAA record points at an address that no longer serves anything, the browser sits there while ping reports perfect health. Force the family to find out:
ping -c 3 -4 example.com
ping -c 3 -6 example.comA difference between those two lines is the answer to the ticket, and the mechanics of why one of them hangs while the other refuses instantly are in what a refusal rules out that a timeout does not.
What to run instead, in one line
If the question is whether the site works, ask the site.
curl -sS -o /dev/null -w 'code %{http_code} ip %{remote_ip} dns %{time_namelookup} tls %{time_appconnect} ttfb %{time_starttransfer}\n' https://example.com/That performs the same sequence a browser does: resolve, connect, handshake, request, wait. Five numbers come back and each one isolates a layer. Resolution slow means DNS. Connect fine and handshake slow or failing means TLS. Everything fast and a bad status code means the application. It replaces ping, telnet-to-port-443 and a stopwatch, and unlike ping it is testing the thing that visitors use.
When you specifically want the port and nothing else, because you are checking whether a service came back up after a restart:
nc -zv example.com 443And when you want to know whether a particular machine is healthy while ignoring DNS entirely, which is the useful test during a migration:
curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/The thing ping is actually the best tool for
Packet loss. Not availability, loss, and it is the one measurement nothing else gives you as cheaply.
A site that is "sometimes slow" and shows nothing wrong in any application metric is frequently a network path dropping a small percentage of packets. Every drop costs a retransmission timeout, which is why five per cent loss feels like a broken site rather than a five per cent slowdown. A single ping tells you nothing about this. A hundred of them tells you everything:
ping -c 100 example.com | tail -3Read the loss percentage and the deviation figure. Consistent low latency with zero loss rules the network out and sends you back to the application. Loss, or a standard deviation as large as the average, is a path problem, and at that point the tool that localises it to a specific hop is mtr rather than traceroute.
One caution on interpreting the result: routers deprioritise ICMP that they have to answer themselves, so a middle hop showing loss while the final destination shows none is normal and means nothing. Loss at the destination is the only loss that counts.
Why any of this matters if you watch sites for other people
Plenty of monitoring configurations, including ones sold as website monitoring, still have a host check that pings an address on an interval. It is cheap, it is fast, and it produces a green light for a machine that has been serving an error page since Thursday.
The client does not experience an IP address answering ICMP. They experience a page. Every layer between those two is where maintained sites actually break, and each layer needs its own assertion: seven questions, and most checkers ask four.
