ping

What it does

ping sends ICMP echo request packets to a target host and listens for ICMP echo reply packets, reporting round-trip time for each and a final summary of packets sent, received, loss percentage, and latency statistics (min/avg/max/mdev). It's usually the very first tool reached for to answer "is this host up and reachable at all?" before digging into DNS, routing, or application-layer issues.

Beginner examples

• ping example.com — ping continuously until interrupted with Ctrl+C
• ping -c 4 example.com — send exactly 4 pings and stop automatically
• ping 192.168.1.1 — ping a device on the local network directly by IP
• ping -q -c 10 example.com — suppress per-packet lines, show only the summary

ping -c 4 8.8.8.8

Advanced examples

• Diagnose a suspected MTU/fragmentation problem by sending a large, non-fragmenting packet: ping -c 4 -s 1472 -M do example.com (a "Frag needed" error indicates an MTU mismatch along the path)
• Watch latency over time to a flaky host while doing other work: ping example.com | ts (with moreutils' ts to timestamp each line)
• Force IPv6 specifically when a host is dual-stack and you want to rule out an IPv6 routing issue: ping -6 -c 4 example.com
• Set a tight timeout to fail fast in a monitoring script rather than waiting on the default OS timeout: ping -c 1 -W 1 example.com

ping -c 100 -i 0.2 -q internal-service.local

Common mistakes

• Concluding a service is down because ping fails, without checking whether ICMP is simply blocked by a firewall while the actual service (port 443, 22, etc.) is fine.
• Running an unbounded ping in a script without -c, causing the script to hang forever waiting for it to be interrupted.
• Misreading high packet loss on WiFi as a "network is down" signal, when it might just be normal wireless interference — cross-check against a wired connection or another device.
• Forgetting sudo is required on some systems/configurations for certain flood or interval settings (-i below 0.2 seconds is typically restricted to root).

Tips

• Use -c in every scripted or automated use of ping — an unbounded ping in a cron job or CI step will hang the job.
• Pair ping with traceroute/mtr when you need to know where along the path latency or loss is occurring, not just whether the endpoint responds.
• The TTL field in ping's output can hint at OS type and approximate hop distance (common defaults: 64 for Linux/macOS, 128 for Windows, 255 for some network gear).

Best practices

• Never rely on ping alone to declare a service healthy or unhealthy — treat it as a network-layer signal and confirm with an application-layer check (HTTP request, TCP connect) for anything customer-facing.
• In monitoring/alerting systems, combine -c and -W to bound both the number of attempts and the per-attempt timeout, so checks fail fast and predictably.
• Be mindful of running high-frequency pings (-i below 1 second) against hosts/networks you don't control — it can look like a denial-of-service probe to automated defenses.

Real-world use cases

• First-line triage during an incident: "is the host even reachable at the network layer?" before investigating application logs.
• Verifying basic connectivity after changing firewall rules, VPN configuration, or DNS records.
• Continuous latency monitoring to a remote host or between two datacenters to spot network degradation trends over time.

Common interview questions

• What protocol does ping use, and on which layer does it operate? ICMP (Internet Control Message Protocol), operating at the network layer (layer 3) — it doesn't use TCP or UDP ports.
• Why might ping fail even though a website loads fine in a browser? Many servers and firewalls block ICMP echo requests specifically while still allowing HTTP/HTTPS traffic; ping failure doesn't necessarily mean the service is down.
• How would you limit a ping to exactly 5 packets with a 2-second timeout each? ping -c 5 -W 2 host.