Without a count it keeps sending. Stop it with `Ctrl+C`, or decide up front with `ping -c 3 host`.

No reply. Is the server down?

Not necessarily. Plenty of servers and cloud networks drop the ICMP packets ping uses while running perfectly well. Check the service itself with `curl` or by connecting to its port.

ping works but my app does not.

ping only proves the network path. Whether the application is listening, and on which port, is a separate question for `curl` or `ssh`.

What is the time value?

The round trip in milliseconds. A sudden rise against the usual figure for the same host means congestion somewhere along the way.

How do I test name resolution alone?

If the name fails and the IP address succeeds, the problem is DNS.

← Linux command list

ping command: check whether you can reach a host

__ __ _ _____

\ \ / /__| |_|_ _|__ _ __ _ __ ___

\ \ /\ / / _ \ '_ \| |/ _ \ '__| '_ ` _ \

\ V V / __/ |_) | | __/ | | | | | |

\_/\_/ \___|_.__/|_|\___|_| |_| |_| |_

A sandbox for trying ping. Nothing here can touch your real files.

user@webterm:~/project$

ping tests whether packets reach a host and come back. Learn why you want `-c`, how to read the output, and how to tell a name problem from a network problem, by running the commands in a real terminal in your browser.

Updated: 2026-09-11

Syntax

ping [-c count] host

It sends small packets and reports whether they come back.

Try it first

Deciding the count up front is the sane default.

$ ping -c 3 example.com
PING example.com (140.32.182.253) 56(84) bytes of data.
64 bytes from 140.32.182.253: icmp_seq=1 ttl=55 time=25.3 ms
64 bytes from 140.32.182.253: icmp_seq=2 ttl=55 time=22.6 ms
64 bytes from 140.32.182.253: icmp_seq=3 ttl=55 time=26.2 ms

--- example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 22.647/24.713/26.172/1.502 ms

-c 3 means send three and stop. Without it, ping keeps going until you interrupt it.

Reading the output

Where	What it tells you
`(140.32.182.253)` on line 1	Which IP the name resolved to
`icmp_seq`	Which packet this is; gaps mean losses
`time=25.3 ms`	The round trip for that packet
`0% packet loss`	How much never came back
`rtt min/avg/max`	Fastest, average and slowest round trip

Two numbers matter: anything other than 0% loss means packets are being dropped, and a time well above the usual means slow.

Using an address

An IP address works in place of a name.

$ ping -c 2 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=1.08 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=1.31 ms

--- 10.0.0.5 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 1.076/1.194/1.312/0.118 ms

localhost checks your own machine.

$ ping -c 1 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.060 ms

--- localhost ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.060/0.060/0.060/0.000 ms

When the name cannot be resolved

If the name never becomes an address, nothing is sent at all.

$ ping nosuchname
ping: nosuchname: Name or service not known

That is a name problem, not a network problem. If the same host answers by IP address, look at DNS.

When you actually reach for it

ping is the first step when someone says they cannot connect.

Situation	What to type
Check the host is reachable	`ping -c 3 server.example.com`
Separate DNS from the network	name fails, then try `ping -c 3 10.0.0.5`
Measure how slow the link is	`ping -c 10 8.8.8.8` and read the average
Sanity-check your own stack	`ping -c 1 localhost`

Once packets get through, move on to curl and see whether the application answers. Working outwards in that order finds the break quickly.

Things that trip people up

Without -c it never stops. Ctrl+C ends it, but writing -c 3 from the start is easier.

No reply does not mean down. Dropping ICMP is a common, deliberate configuration. "Ping fails but the website is fine" is an everyday situation.

A reply does not mean healthy. ping proves the path and nothing more. Use curl for the service and ssh for a login.

The count has to be at least 1.

$ ping -c 0 example.com
ping: invalid argument: '0': out of range: 1 <= value <= 2147483647

Practise it hands-on

webterm.appthis site

Advanced Terminal Commands
Learn commands for specific situations
Try the tutorial

learn.webterm.appa separate site

>_WEBTERM LEARN

WebTerm Learn: from one command to actually using it

Commands stick when they show up in a real sequence of work, not one at a time. There is a course that builds them up in order.

See the course

Related commands

curl / ssh / scp / ip

Frequently asked questions

ping will not stop.: Without a count it keeps sending. Stop it with `Ctrl+C`, or decide up front with `ping -c 3 host`.
No reply. Is the server down?: Not necessarily. Plenty of servers and cloud networks drop the ICMP packets ping uses while running perfectly well. Check the service itself with `curl` or by connecting to its port.
ping works but my app does not.: ping only proves the network path. Whether the application is listening, and on which port, is a separate question for `curl` or `ssh`.
What is the time value?: The round trip in milliseconds. A sudden rise against the usual figure for the same host means congestion somewhere along the way.
How do I test name resolution alone?: If the name fails and the IP address succeeds, the problem is DNS.