Ping: The First Tool I Reach For

Ping is the first command I run when something's broken. Before checking logs, before SSHing into servers, before opening monitoring dashboards - I ping. It takes seconds and immediately tells me if the problem is network connectivity or something else.

What Ping Actually Tests

Ping sends ICMP echo requests and waits for responses. It tells you:

Is the host reachable? - Basic connectivity
How long does it take? - Round-trip latency
Are packets being dropped? - Packet loss percentage

ping google.com

PING google.com (142.250.182.142): 56 data bytes
64 bytes from 142.250.182.142: icmp_seq=0 ttl=117 time=14.7 ms
64 bytes from 142.250.182.142: icmp_seq=1 ttl=117 time=12.1 ms
64 bytes from 142.250.182.142: icmp_seq=2 ttl=117 time=13.5 ms

Each line shows:

icmp_seq - Sequence number. Missing numbers = dropped packets.
ttl - Hops remaining. Lower TTL = more routers between you and target.
time - Round-trip time in milliseconds.

Options I Use Regularly

Limit the count:

ping -c 5 google.com    # Linux/macOS: 5 pings then stop
ping -n 5 google.com    # Windows equivalent

Continuous ping on Windows:

ping -t google.com      # Runs until Ctrl+C

Test MTU issues:

ping -s 1472 google.com     # Linux/macOS: Larger packet
ping -l 1472 google.com     # Windows equivalent

With an 8-byte ICMP header, 1472 bytes creates a 1500-byte packet - standard Ethernet MTU. If this fails but smaller pings work, you've found an MTU problem.

My Troubleshooting Pattern

Step 1: Ping an IP address

ping 8.8.8.8

This bypasses DNS. If this fails, it's a network problem.

Step 2: Ping a hostname

ping google.com

If IP works but hostname fails, it's DNS.

Step 3: Ping your gateway

ping 192.168.1.1

If you can't reach your gateway, check local network/WiFi.

This pattern isolates problems in under a minute.

Interpreting Results

High RTT (>100ms for local, >300ms for cross-continent): Network congestion or routing issues. Check if it's consistent or spiky.

Variable RTT (jitter):

time=15.2 ms
time=145.3 ms
time=22.1 ms
time=189.4 ms

Unstable connection. Common with overloaded WiFi or congested links.

Packet loss: Missing sequence numbers or loss percentage in summary. Even 1-2% loss causes noticeable problems for real-time applications.

What Ping Can't Tell You

ICMP is often blocked. No response doesn't mean the host is down. Firewalls frequently drop ICMP while allowing TCP/UDP.

It doesn't test your application. A host that pings fine might have a crashed web server. Ping tests network layer, not services.

One-way problems are hidden. Ping shows round-trip time. If the path to the server is fine but the return path is broken, you'll still see failures.

Rate limiting exists. Some networks throttle ICMP. Your ping might show loss that doesn't affect actual traffic.

When Ping Isn't Enough

If ping works but your app doesn't, try:

# Test a specific port
nc -zv hostname 443

# Check HTTP specifically
curl -I https://hostname

# Trace the path
traceroute hostname   # Linux/macOS
tracert hostname      # Windows

Key Takeaways

Ping IP first, then hostname - this separates network from DNS issues
TTL changes over time might indicate routing changes
High jitter is often worse than high but stable latency
No ping response doesn't mean the host is down - ICMP might be blocked
For service-level testing, use nc, curl, or telnet instead