2026
ping: The First Tool You Reach For
What ping actually does, how ICMP works under the hood and what the output is really telling you when something on the network stops responding.
The first command I ever typed when something on the network was not working was ping. I did not really know what it did. I just knew it was the thing you tried. The output came back with a bunch of numbers and I nodded like it confirmed something, then went back to googling the actual problem.
It took a while before I stopped treating ping as a magic incantation and started understanding what the output was actually telling me. Once that clicked, it became one of the most useful tools in my regular rotation. Not because it solves complex problems on its own, but because it answers a very specific question extremely fast: is there a path from here to there?
What ping actually does
Ping sends a message called an ICMP Echo Request to a destination address. The destination, if it is configured to respond, sends back an ICMP Echo Reply. Ping measures how long that round trip takes. That is the entire mechanism.
ICMP stands for Internet Control Message Protocol. It is part of the IP suite but it is not TCP and it is not UDP. It sits at layer 3 of the OSI model, right alongside IP itself. You do not open a TCP connection or specify a port when you use ping. The protocol handles its own identification through the ICMP message type field. Type 8 is the Echo Request. Type 0 is the Echo Reply.
Originally defined in RFC 792 back in 1981, ICMP was designed to carry error messages and operational information about IP networks. Ping is just one of its uses. Others include the traceroute utility, which also relies on ICMP messages, specifically the Time Exceeded responses that routers send back when a packet's TTL runs out.
Reading the output
Running ping google.com produces something like this:
PING google.com (142.250.74.46): 56 data bytes
64 bytes from 142.250.74.46: icmp_seq=0 ttl=117 time=11.4 ms
64 bytes from 142.250.74.46: icmp_seq=1 ttl=117 time=10.9 ms
64 bytes from 142.250.74.46: icmp_seq=2 ttl=117 time=11.1 ms
64 bytes from 142.250.74.46: icmp_seq=3 ttl=117 time=10.8 ms
--- google.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.8/11.05/11.4/0.224 ms
Each line in the output is one packet making the round trip. Here is what the fields mean:
64 bytes from 142.250.74.46The ICMP reply came back and contained 64 bytes. The IP address is the one that actually responded.
icmp_seq=1The sequence number of this particular packet. Each one increments by one. Gaps in this number mean packets were lost.
ttl=117Time To Live. Starts at a value set by the sender and decrements by one at every router hop. When it hits zero the packet is discarded. This value tells you roughly how many hops the reply travelled.
time=11.4 msThe round-trip time. How long the packet took to leave your machine, reach the destination and come back. This is the number most people actually care about.
The summary at the bottom is where you get the aggregate picture. Packet loss percentage tells you if anything was dropped. The min, average, max and standard deviation for round-trip time tell you both the typical latency and how consistent it is.
What you can actually learn from it
People reach for ping in a few different situations. Each one is asking a slightly different question.
Is the host reachable at all?
The most basic use. If you get replies, there is a network path between you and the destination. If you get nothing, the host might be down, the IP might be wrong, a firewall might be blocking ICMP traffic, or the route might not exist.
Is there packet loss?
Run ping for a minute and watch the sequence numbers. If icmp_seq jumps from 4 to 7, packets 5 and 6 were dropped somewhere. The summary at the end shows you the percentage of packets lost over the whole session.
How stable is the connection?
Consistent round-trip times suggest a stable path. Times that bounce between 12 ms and 300 ms tell a different story. Jitter like that can cause real problems for anything latency-sensitive.
A rough sense of distance
Lower round-trip times generally mean the destination is physically closer, or at least fewer hops away. Pinging a server in the same data centre should be under a millisecond. Pinging one on another continent will typically be well over 100 ms.
TTL: more than just a countdown
The TTL value in a ping response deserves a bit more attention. When a packet is sent, the operating system sets an initial TTL. Every router that forwards the packet decrements that value by one. If it hits zero before reaching the destination, the router discards the packet and sends back an ICMP Time Exceeded message.
This exists to prevent packets from looping forever in the event of a routing loop. Without TTL, a misrouted packet would bounce between routers indefinitely.
Different operating systems start with different default TTL values. Linux typically uses 64. Windows uses 128. Many network devices use 255. When you see a TTL of 117 in a ping response, that tells you the packet passed through roughly 11 hops on its way back to you, assuming the sender started at 128. It is not an exact science, but it gives you a rough sense of how many routers the traffic traversed.
64Common on most Linux distributions128Default across modern Windows versions255Used by many network appliancesUseful flags
By default, ping on Linux keeps going until you stop it with Ctrl+C. On macOS it also runs indefinitely. Most of the time you want to limit it. These are the flags worth knowing:
-c <n>-i <sec>-s <bytes>-t <ttl>-W <ms>A typical invocation when you just want a quick check looks like ping -c 4 192.168.1.1. Four packets, then a summary. Clean and done.
What ping cannot tell you
Ping is a narrow tool. It answers one question well. But it gets misread often enough that it is worth being explicit about where it falls short.
Firewalls can silence ICMP
Many hosts are configured to ignore ping entirely. A non-response does not prove the host is down. It might just mean ICMP is filtered.
It only tests ICMP
A host that responds to ping might still have its web server down, its database refusing connections, or its application crashed. Ping tells you the network path works. Nothing more.
ICMP can be deprioritised
Routers are allowed to treat ICMP packets as low priority. Your ping times might look bad while your actual application traffic flows fine over the same path.
It measures round-trip time
The time you see is there and back. If the response takes 20 ms, the one-way latency is roughly half that. Roughly, because the path outbound and the path inbound are not always identical.
A small tool with a clear job
What makes ping useful is exactly what makes it limited. It does one thing: it fires an ICMP packet at an address and waits for a response. That simplicity means you always know what you are actually testing.
When I reach for ping now it is not out of habit. It is because I want a fast answer to a specific question before I start looking deeper. Is this host responding? Is there packet loss on this path? Is the latency what I expect? If any of those answers are wrong, that tells me where to dig next.
It will not tell you why your application is slow. It will not tell you your certificate is expired. It will not tell you your database is out of connections. But when the most basic question is still unanswered (can this machine even talk to that one), ping is where you start.