ping: Test Basic Connectivity in CI
ping sends ICMP echo requests to a host and reports which replies came back and how long they took.
ping answers the first question in any connectivity debug: can this host reach that host at all. The catch in CI is that many networks block ICMP, so a failed ping does not always mean a failed service.
What it does
ping sends ICMP echo request packets and listens for echo replies, printing round-trip time per packet and a loss summary at the end. It tests layer-3 reachability and DNS resolution of the name, but says nothing about whether a TCP service is listening.
Common usage
# send 4 packets and exit (do not ping forever in CI)
ping -c 4 db.internal
# bound the wait so an unreachable host fails fast
ping -c 1 -W 2 db.internalOptions
| Flag | What it does |
|---|---|
| -c <count> | Stop after sending N packets |
| -W <secs> | Timeout to wait for a reply (Linux iputils) |
| -i <secs> | Interval between packets |
| -n | Numeric output, do not resolve addresses |
| -4 / -6 | Force IPv4 or IPv6 |
In CI
Always pass -c or ping runs until killed and hangs the job. Treat a ping failure as inconclusive, not proof a service is down: cloud networks and many container setups drop ICMP while TCP still works. Use nc -z to test the actual service port.
Common errors in CI
"ping: <host>: Name or service not known" is a DNS failure, not a reachability one; debug it with getent hosts or dig. "Destination Host Unreachable" or 100% packet loss can mean a blocked ICMP rather than a dead host. "ping: socket: Operation not permitted" means the container lacks the capability for raw or ICMP sockets.