ping network
is it down or is it just you? one command to find out.
The ping man page is 500 lines long. You need one command and it answers the most fundamental question in networking: can I reach this thing?
Your website went down. Or your server stopped responding. Or your internet “feels slow.” So you opened a browser. You typed the URL. You stared at a loading spinner. Nothing happened. You opened a new tab. You Googled “is [website] down.” You landed on downforeveryoneorjustme.com. You typed the URL again. You waited for that page to load — which only works if your internet is working, which is the thing you’re trying to figure out.
ping answers the question before the browser finishes rendering its loading spinner. It sends a tiny packet to a host and measures how long the response takes. If it responds, the host is alive. If it doesn’t, something is broken. If it responds slowly, now you know your internet isn’t “fine.”
Unless you’re running Windows then wtf none of this applies to you. But hey, come to the dark side, go install WSL2 and you can follow along. We’ll wait. Impatiently.
If you’re lazy like me (all sysadmins are!) then click here for the ping cheat sheet.
Ping a host
ping google.com
PING google.com (142.250.80.46) 56(84) bytes of data.
64 bytes from lax17s55-in-f14.1e100.net: icmp_seq=1 ttl=117 time=5.23 ms
64 bytes from lax17s55-in-f14.1e100.net: icmp_seq=2 ttl=117 time=4.89 ms
64 bytes from lax17s55-in-f14.1e100.net: icmp_seq=3 ttl=117 time=5.11 ms
On Linux, ping runs continuously until you Ctrl+c it. Each line is one round trip — your machine sent a packet, the remote host replied, and ping measured how long it took.
- time=5.23 ms — latency. How long the round trip took. Under 50ms is good. Over 200ms is noticeable. Over 1000ms means something is wrong.
- ttl=117 — time to live. How many network hops are left. Mostly useful for advanced debugging.
- icmp_seq — sequence number. If these skip (1, 2, 4, 5), you’re dropping packets.
Stop after N pings
ping -c 5 google.com
Five pings and done. Shows a summary at the end with min/avg/max latency and packet loss percentage.
--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 4.891/5.108/5.432/0.178 ms
0% packet loss. Average latency 5.1ms. Everything is fine. Move on with your life.
Diagnose common problems
“Is my internet working?”
ping -c 3 8.8.8.8
Ping Google’s DNS by IP. If this works, your internet connection is up. If it fails, your network is broken at a fundamental level — check your cable, WiFi, or router.
“Is it a DNS problem?”
ping -c 3 8.8.8.8 # works?
ping -c 3 google.com # fails?
If the IP works but the domain doesn’t, DNS resolution is broken. Your internet is fine — your DNS isn’t resolving hostnames. Check /etc/resolv.conf or try dig @8.8.8.8 google.com to verify.
“Is it the server or the network?”
ping -c 5 your-server.com
- All replies — the server is reachable, the problem is likely application-level (web server down, service crashed)
- No replies — the server is unreachable. Down, firewalled, or network path broken
- Some replies missing — packet loss. Network congestion, bad cable, dying switch, or overloaded server
“Is it slow?”
ping -c 20 your-server.com
Watch the latency numbers. Consistent 5ms? Normal. Jumping between 5ms and 500ms? Jitter. That means network congestion or a bad hop somewhere. Run traceroute to find where.
Set the interval
ping -i 0.5 google.com
Ping every 0.5 seconds instead of the default 1 second. Faster feedback when debugging. Requires root for intervals under 0.2 seconds.
ping -i 10 google.com
Ping every 10 seconds. For long-running monitoring — leave it running in a tmux session to watch for intermittent issues.
Set the packet size
ping -s 1400 -c 5 google.com
Sends 1400-byte packets instead of the default 56. Useful for testing MTU (Maximum Transmission Unit) issues. If small pings work but large pings fail, you have an MTU problem — packets are too big for some hop in the network path and aren’t being fragmented correctly.
Test MTU discovery
ping -M do -s 1472 -c 3 google.com
-M do sets “don’t fragment.” If the packet is too big for any hop, you’ll get an error instead of silent fragmentation. 1472 + 28 bytes of headers = 1500, the standard Ethernet MTU. If this fails, try smaller sizes until it works — that’s your path MTU.
Ping IPv6
ping6 google.com
Or on newer systems:
ping -6 google.com
Tests IPv6 connectivity specifically. If IPv4 ping works but IPv6 doesn’t, your IPv6 configuration needs attention.
Timestamps
ping -D google.com
Prepends a Unix timestamp to each line. Useful when logging ping output to a file for later analysis:
ping -D google.com > ping_log.txt &
Run it in the background, check the file later to find when latency spiked or packets started dropping.
The flags that actually matter
| Flag | What it does |
|---|---|
-c N |
Send N pings and stop. |
-i N |
Set interval between pings (seconds). |
-s SIZE |
Set packet size in bytes. |
-W SECS |
Timeout — wait N seconds for a reply. |
-M do |
Set don’t fragment flag (MTU testing). |
-D |
Print timestamps on each line. |
-q |
Quiet — only show summary at the end. |
-6 |
Force IPv6. |
-I IFACE |
Use a specific network interface. |
-f |
Flood ping — as fast as possible (requires root). |
“But I just—”
Let me guess.
“I just check downforeveryoneorjustme.com.” You opened a browser, navigated to a website, typed a URL, and waited for a response — to check if your internet works. If your internet is down, that website won’t load either. ping 8.8.8.8 works even when DNS is broken, your browser is crashed, and everything else has gone sideways. It’s the first diagnostic tool, not the backup plan.
“I use an uptime monitoring service.” Uptime monitoring tells you when something is down — after the fact, via email, with a delay. ping tells you right now, from your perspective, with latency numbers. The monitoring service tells you the house is on fire. Ping tells you if the fire truck can reach it.
“My network monitoring dashboard shows connectivity.” Dashboards are great for trends and history. When something is broken right now and you’re SSH’d into a server at 2 AM, you’re not opening Grafana on your phone. You’re typing ping -c 5 gateway-ip and working from there.
“Ping doesn’t work on some hosts.” Correct. Some servers block ICMP (the protocol ping uses). Cloudflare, AWS ELBs, and some corporate firewalls drop ping requests. That doesn’t mean ping is useless — it means those specific hosts chose not to respond. For everything else — your routers, gateways, internal servers, DNS servers — ping works perfectly.
ping cheat sheet
You made it. Or you skipped straight here. Either way, no judgment. Copy and paste these. Pin them. Tattoo them on your forearm. Whatever works.
| What you’re doing | Command |
|---|---|
| Basic ping (5 packets) | ping -c 5 google.com |
| Test internet (by IP) | ping -c 3 8.8.8.8 |
| Continuous ping | ping google.com (Ctrl+c to stop) |
| Fast interval | ping -i 0.5 google.com |
| Large packet (MTU test) | ping -s 1400 -c 5 host |
| Don’t fragment (MTU discovery) | ping -M do -s 1472 -c 3 host |
| IPv6 | ping -6 google.com |
| With timestamps | ping -D google.com |
| Summary only | ping -q -c 20 google.com |
| Log to file | ping -D host > ping.log & |
The diagnostic ladder:
ping 8.8.8.8(internet up?) →ping google.com(DNS working?) →ping your-server(server reachable?) → traceroute (where’s the problem?). That’s the whole troubleshooting flow.