Ping

This is not ICMP, and the difference is not cosmetic

Real ping sends an ICMP Echo Request and times the Echo Reply. Crafting ICMP needs a raw socket, which a serverless function does not get — so rather than pretend, this tool sends four DNS resolutions for the name you entered and times each. That is a usable liveness indicator, and it makes three common conclusions wrong.

• The latency is to a resolver, not to the host. What is timed is a question answered by the recursive resolver our server uses. Unless it has to walk out to the domain's authoritative nameservers, the number has nothing to do with the distance to your target: a cached answer returns in a millisecond or two wherever the host is. Four uniformly tiny figures mean you are measuring a cache.
• Success does not mean the host is up. A name resolves because somebody published a record. The machine behind it can be powered off, and the probes will all succeed.
• An IP address is not a valid target here. There is no name to resolve, so there is no probe to send. This tool needs a hostname.

What even a real ping would not prove

The most frequent mistake in network troubleshooting, and it survives every improvement to the measurement.

• A reply does not mean the service works. ICMP is answered by the IP stack, not the application. A host that pings perfectly can have the daemon stopped, the listener on the wrong interface, the certificate expired, the disk full or the database unreachable. "It pings" is the start of troubleshooting, never the end.
• Silence does not mean the host is down. Echo is the first thing an ACL or host firewall drops, and even when permitted it is routinely rate limited or deprioritised along the way. Every Windows host blocks it by default. A policy that permits your application and drops echo is correct, and it makes a working service look dead.
• The latency is control-plane latency. A router generates an ICMP reply in software while forwarding traffic in hardware, so a hop showing 200 ms may be moving your traffic in two — it was busy answering you. Diagnosing a path from ping times alone gives confident conclusions about the wrong hop.

Reading the three numbers

The average over four probes is a weak statistic; the spread is the interesting part. Four similar values mean a stable path; one outlier among three fast answers is usually a cache expiring; and high-but-steady looks nothing like values that swing — that swing is jitter, which is what breaks voice and video. Four probes tells you whether to look further, not what to put in a ticket.

Loss is binary per probe and there are four, so it can only report 0, 25, 50, 75 or 100 percent. Treat anything between as "look again properly": a quarter of four probes is one probe.

When to use something else

Almost always, honestly: your own machine has ping and it measures from where your problem is. This page is for a probe from outside your network — telling an internal failure from an internet-facing one — and for when you have no shell. For a real reachability test on a port in use, the port scanner completes a TCP handshake, a far stronger statement than an echo reply, and the DNS lookup shows the records rather than only timing the question.

When the problem is the path rather than the endpoint, network-path-analyzer walks it hop by hop from a device you control, and path-mtu-analyzer finds the failure that defeats ping entirely — small packets pass, the connection establishes, anything large is silently dropped. To watch latency and loss over time rather than sample once, network-monitoring-observability covers measuring it so the numbers mean something, and interface-utilization answers the question ping raises most often: is the link simply full?