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.

Back to the top, you overachiever.