The ping Command: Reading Every Line of the Output

The ping command sends ICMP echo request packets to a host and prints what comes back. Each reply line carries icmp_seq (packet order), ttl (hops left) and time (round-trip milliseconds). The closing block gives packet loss and rtt min/avg/max/mdev, where the last figure is jitter. A reply proves the host answers ICMP, nothing more.

Key takeaways

• Read the output in three parts: the header line, the reply lines, and the closing statistics block.
• ttl is a hop counter, not a time. Subtract it from the nearest standard start value (64, 128 or 255) to estimate hops.
• The last figure in rtt min/avg/max/mdev is jitter, and it predicts how a call or a game feels better than the average does.
• The flags are not portable. -t means ping forever on Windows, set TTL on Linux, and quit after N seconds on macOS.
• A failed ping does not mean a website is down, and a successful one does not mean it is up. Filtering ICMP is normal policy.

What the ping command actually does

The definition of ping is short: it sends an ICMP echo request to an address and waits for an echo reply. That is the whole mechanism. What the ping command does is measure one thing precisely, how long a small packet takes to reach a host and come back, which is called the round-trip time. Everything else you can learn from ping is inference drawn from that one measurement, or from its absence.

The packets are defined in RFC 792: an echo request is ICMP type 8, an echo reply is type 0. Over IPv6 the same pair are types 128 and 129. They are handled by the operating system kernel, not by any application, which is the single most important fact about ping and the reason it can mislead you. Nothing on the host has to be working except the network stack itself.

Mike Muuss wrote the original in December 1983 and named it after the sound a sonar makes, so the meaning of the word is literal: emit a pulse, listen for the echo. The expansion "Packet InterNet Groper" came later and is a backronym. Keep the sonar reading, because it sets the right expectation. Sonar tells you something is out there and roughly how far away. It does not tell you what it is or whether it works.

A real ping run, annotated

Here is a complete run on Linux against google.com, with a fixed count of five packets so it stops on its own:

ping -c 5 google.com

PING google.com (142.250.185.174) 56(84) bytes of data.
64 bytes from fra16s52-in-f14.1e100.net (142.250.185.174): icmp_seq=1 ttl=116 time=13.2 ms
64 bytes from fra16s52-in-f14.1e100.net (142.250.185.174): icmp_seq=2 ttl=116 time=12.9 ms
64 bytes from fra16s52-in-f14.1e100.net (142.250.185.174): icmp_seq=3 ttl=116 time=14.6 ms
64 bytes from fra16s52-in-f14.1e100.net (142.250.185.174): icmp_seq=4 ttl=116 time=12.7 ms
64 bytes from fra16s52-in-f14.1e100.net (142.250.185.174): icmp_seq=5 ttl=116 time=13.1 ms

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 12.744/13.301/14.612/0.679 ms

Three sections, and each answers a different question. The header line tells you what ping decided to talk to. The reply lines tell you what came back and how fast. The statistics block tells you what the run added up to. Take them in order.

The header line

PING google.com (142.250.185.174) 56(84) bytes of data.

This line is a receipt for two things that happened before any packet left your machine. First, the hostname was resolved to an IP address, and that address is printed in brackets. If you were expecting a different address, stop reading the rest of the output: your problem is DNS or a stale record, and the DNS lookup tool or the website IP lookup will show you what the world resolves that name to. Ping an IP address directly and this step is skipped entirely, which is exactly why ping 8.8.8.8 is the standard test for "is my connection working, ignoring DNS".

Second, the size. 56(84) bytes means 56 bytes of payload, which becomes 84 on the wire once you add the 8-byte ICMP header and the 20-byte IPv4 header. Windows prints "with 32 bytes of data" instead, because its default payload is 32 bytes. Neither default matters until you are hunting an MTU problem, which is further down.

The reply lines

64 bytes from fra16s52-in-f14.1e100.net (142.250.185.174): icmp_seq=1 ttl=116 time=13.2 ms

One line per packet that came back. Five fields, each worth reading:

One quiet platform difference: Linux numbers the first packet icmp_seq=1, while macOS and the BSDs start at icmp_seq=0. Windows does not print sequence numbers at all, which is why a lost packet on Windows shows up as a "Request timed out." line rather than a gap in a counter.

What a round-trip time should look like

Round-trip time is bounded by physics before it is bounded by anything you can fix. Light in fibre covers roughly 200 km per millisecond, and a round trip travels the distance twice, so there is a floor under every link that no amount of tuning removes. These are the ranges to calibrate against:

The number that matters is not the one in the table, it is the difference from your own normal. A path that has always been 12 ms and is now 90 ms is a problem even though 90 ms would be fine for someone on another continent. This is what latency baselining is for, and it is the argument for measuring continuously rather than only when something feels wrong.

TTL is a hop counter, not a time

TTL stands for Time To Live, and the name is a historical accident that misleads almost everyone who meets it. RFC 791 originally intended it as a lifetime in seconds. In practice, every router implements it as a counter: it takes 1 off the TTL of every packet it forwards, and if the value hits 0 the packet is discarded and an ICMP Time Exceeded message is sent back to the sender. It is a loop-prevention device. Nothing about it is measured in time.

The field is 8 bits, so the maximum is 255. Operating systems pick a starting value and stick to it, and the common ones are consistent enough to be useful:

Estimating hop count from the TTL you see

The value in a reply line is what was left after the trip, so you can work backwards. Take the TTL you see, round up to the nearest standard starting value above it, and subtract. In the run above, ttl=116 rounds up to 128, so the reply crossed about 12 routers on its way to you. A reply showing ttl=53 rounds up to 64 and came about 11 hops.

Treat this as an estimate, with three honest caveats. Operators can and do change the initial TTL, so the standard values are conventions rather than rules. Some middleboxes and tunnels rewrite the field. And the TTL you see reflects the return path only, which on the internet is frequently not the same as the outbound path, so it is not a hop count for your traffic going out. If you want the real path, that is what traceroute is for, and traceroute works precisely by sending packets with a TTL of 1, then 2, then 3, collecting the Time Exceeded error from each router in turn.

The statistics block, which is where the answer usually is

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 12.744/13.301/14.612/0.679 ms

Read the first line left to right. 5 packets transmitted, 5 received is the raw count, and the percentage after it is just those two numbers expressed as loss. The time 4006ms at the end catches people out: it is the wall-clock duration of the whole run, not a latency figure. Five packets at the default one-second interval means the run spans four one-second gaps, so any figure a little over 4000ms is exactly what you expect and tells you nothing about the network.

Reading packet loss

Packet loss is the first number to look at, because loss and latency fail differently and loss is usually worse. A healthy wired path returns 0%. Sustained loss of 1% to 2% is enough to make a voice call choppy and a video call freeze, because TCP treats every lost packet as congestion and backs off. Above 5% sustained, something is genuinely broken.

There is one caveat that saves a lot of wasted investigation. Routers rate-limit and deprioritise ICMP on purpose, because generating replies costs CPU on a device whose job is forwarding. So loss that only appears when you ping hard, with a flood or a large payload, is often the router protecting itself rather than the path dropping your real traffic. Loss that shows up at a steady one packet per second, over minutes, is real.

The rtt line, and why the last number is the important one

Four figures: minimum, average, maximum, and a spread. Linux labels the last one mdev; macOS and the BSDs print stddev in the same slot. Either way it measures how far individual round trips scatter around the average, which is what everyone means by jitter.

Most people read the average and stop. That is the wrong number to stop on. The average tells you how far away something is. The spread tells you how the connection feels, because anything real-time has to buffer for the worst case rather than the typical one. A path averaging 40 ms with 2 ms of jitter carries a clean voice call. A path averaging 25 ms with 30 ms of jitter is a faster path on paper and an unusable one in practice: the receiver has to hold audio back to cover the late packets, and when it guesses wrong you hear a dropout.

A quick way to read the line without doing arithmetic: compare min and max. In the run above they are 12.7 and 14.6, a spread of under 2 ms, which is a stable path. If max is several times min, something on the route is queueing your packets, and the average is hiding it. That relationship between latency, jitter and what a user actually experiences is the same one that makes response time percentiles more useful than response time averages.

64

the initial TTL Linux and macOS put on outgoing packets; Windows uses 128

32

bytes of payload Windows ping sends per packet; Linux and macOS send 56

4

echo requests Windows sends before stopping; Linux keeps going until Ctrl+C

1472

the largest ping payload that fits a 1500-byte Ethernet MTU without fragmenting

The same command, three different flag sets

The Linux ping command, the macOS one and the Windows one are three separate programs that happen to share a name. Their flags overlap enough to feel portable and differ enough to bite. The first difference you meet is the default: ping in Command Prompt on Windows sends four packets and exits, while on Linux and macOS it runs until you stop it. Here is what each one wants:

Two more Linux notes. Only root may set -i below 2 ms, and only root may run flood mode -f with a zero interval, because both let you generate a lot of traffic very quickly. Do not point either at a host you do not own: from the far end it is indistinguishable from an attack.

Continuous ping, and logging an intermittent fault

The problems worth investigating with ping are rarely the ones happening while you watch. A connection that drops for eight seconds twice a day will never appear in a five-packet test. The fix is to leave a ping running with timestamps, and read the file afterwards.

On Linux and macOS, ping already runs until you stop it. Add -i to slow it down so the log stays readable. On Linux, two more flags make the log worth reading afterwards: -D puts a Unix timestamp on every line, and -O prints a line for packets that got no answer. Without -O a lost packet leaves no trace at all in the file, just a gap in the sequence numbers you would have to spot by eye. Wrap the whole thing in stdbuf -oL so the output reaches the file line by line instead of sitting in a buffer:

# One packet every 5 seconds, timestamped, losses recorded, appended to a file
stdbuf -oL ping -D -O -i 5 8.8.8.8 >> ~/ping-8888.log 2>&1 &

# Later: how many replies, and how many losses?
grep -c "bytes from" ~/ping-8888.log
grep -c "no answer yet" ~/ping-8888.log

# Pull out only the slow ones (over 100 ms)
grep -E "time=[0-9]{3,}" ~/ping-8888.log

On Windows, -t is what makes ping continuous, and it has a feature worth knowing: press Ctrl+Break and it prints the running statistics so far and keeps going. Ctrl+C stops it. Windows ping does not timestamp its output, so if you want to correlate a drop with anything else, add the timestamp in PowerShell:

REM Command Prompt: runs until Ctrl+C, Ctrl+Break for interim stats
ping -t 8.8.8.8

REM PowerShell: same thing, with a timestamp on every line
ping -t 8.8.8.8 | ForEach-Object { "$(Get-Date -Format o) $_" } | Tee-Object -FilePath ping.log

Two things to control before you trust the log. Ping from a wired machine if you can, because a ping over Wi-Fi measures your Wi-Fi and will happily blame the internet for a bad access point. And ping two targets at once, your own gateway and something external such as 8.8.8.8, so that when loss appears you can immediately see whether it starts inside your network or outside it.

Reading the failures: each one points somewhere different

When ping fails, the specific message is the diagnosis. The most common mistake is treating them all as "it did not work" when they are telling you about completely different parts of the path. Read who sent the message as carefully as you read the message itself.

The pattern worth internalising: an error message means some device on the path identified itself and told you what went wrong, which is genuinely useful. A timeout means nothing answered, which is barely information at all. If you are staring at timeouts, the next tool is traceroute, not another ping.

A failed ping does not mean the website is down

This is the part that matters most, and it cuts both ways.

No reply does not mean the host is down. Filtering ICMP is ordinary, deliberate policy across large parts of the internet, and it has been for two decades. AWS security groups allow no inbound traffic until you write a rule, and ICMP echo request needs its own rule, so a freshly launched EC2 instance serving traffic perfectly will not answer a ping. Windows Defender Firewall blocks inbound echo requests on the private and public profiles by default, which is why a healthy Windows box on a new network ignores you until somebody enables the File and Printer Sharing (Echo Request - ICMPv4-In) rule. Plenty of corporate firewalls drop echo requests at the edge as a matter of course. Getting nothing back from a host tells you that host does not answer ICMP from where you are. It is not a diagnosis.

A reply does not mean the website is up. ICMP is handled by the kernel, so an echo reply proves the machine has power, an IP address and a functioning network stack. It says nothing about anything running on top. The web server can be returning 500s to every request, the TLS certificate can have expired an hour ago, the database can be refusing connections, the application can be deadlocked and serving a blank page. All of that is invisible to ping, and every one of those is an outage to your users.

There is a third trap specific to modern hosting. If a domain sits behind a CDN or a reverse proxy, the thing that answers your ping is the edge, not your server. Ping a Cloudflare-proxied hostname and you get a fast, healthy reply from a Cloudflare data center near you while your origin sits dead in a rack somewhere. The ping succeeded. The website is down. Nothing about the output hinted at it.

ping vs traceroute vs curl vs an uptime check

Each of these proves something narrow, and knowing the boundaries saves you from concluding too much from one of them:

The usual sequence when something is wrong: ping to see whether the host is reachable at all, traceroute to find where the path breaks if it is not, and curl to find out whether the application is actually working if it is. Ping is the first step because it is the cheapest, not because it is the most informative.

Ping recipes worth keeping

How to use the ping command well comes down to asking a specific question instead of a vague one. To ping an IP address from a Linux or macOS shell, or in Command Prompt on Windows, these are the runs worth keeping:

# Is my connection working at all, ignoring DNS entirely?
ping -c 4 8.8.8.8                 # Linux, macOS
ping -n 4 8.8.8.8                 # Windows

# Is DNS the problem? Compare these two.
ping -c 4 8.8.8.8
ping -c 4 example.com

# Is my own gateway healthy, or does the trouble start upstream?
ping -c 20 192.168.1.1

# Quick jitter sample: 20 packets, fast, then read mdev
ping -c 20 -i 0.2 8.8.8.8

# Is there an MTU problem? 1472 + 8 ICMP + 20 IP = 1500
ping -c 3 -M do -s 1472 8.8.8.8   # Linux
ping -c 3 -D -s 1472 8.8.8.8      # macOS
ping -f -l 1472 -n 3 8.8.8.8      # Windows

The MTU one is worth explaining because it is the most useful non-obvious trick here. The Do Not Fragment bit stops routers splitting your packet, so if a payload of 1472 fails while 1400 succeeds, something on the path has an MTU below 1500. That is the classic signature of a VPN or a PPPoE link, where a page starts loading and then stalls forever. Step the size down until it succeeds and you have found the working MTU. Note that this still is not a bandwidth test: you are probing packet size, not speed.

One safety note on -f: on Windows it sets Do Not Fragment, but on Linux the same letter means flood ping, which fires packets as fast as the host replies. Same flag, wildly different consequences.

Using ping as a network health check

Everything above is ping as a hand tool. Run on a schedule, it becomes a health check, and the honest scope of that check is narrow but real.

Scheduled ICMP checks are the right instrument for anything that has an IP address and no HTTP surface: routers, switches, firewalls, VPN endpoints, printers, IoT devices, database servers, a bare host you want to know is alive. For these, ICMP reachability is the health question, and ping monitoring answers it directly, with the round-trip time doubling as an early warning that something on the path is degrading before it fails outright.

For a website, ICMP is the wrong check on its own, for both reasons above: a healthy host may not answer it, and a broken one may answer perfectly. The pairing that works is an HTTP check that requests a real URL and validates the status code, with an ICMP check alongside it when you also want to know the machine is reachable. The gap between the two is often what locates the fault: HTTP failing while ICMP passes means the box is up and the application is not.

Do the baselining while things are healthy. Ping is far more useful when you can say "this path has run at 14 ms with 0.5 ms of jitter for six months" than when you meet it for the first time mid-incident. Without history, a number has nothing to be compared against.

See how Pulsetic's ping monitoring catches this from the outside, across 15+ locations.