Ping – Complete Guide to ICMP Echo, Latency and Packet Loss

"Is the server up?" is usually the first question in any incident, and ping is usually the first command people type to answer it. It tells you whether a host answers ICMP echo requests, how long each round trip takes and whether any replies went missing. That makes it the fastest way to separate "the host is unreachable" from "the network path is slow" from "the application is broken".

The NetTools.tech Ping tool runs that test from our server instead of from your machine. That is useful when you need an outside view: checking whether a public server is reachable from the internet, comparing with a ping from inside your network, or testing from a location other than your own office or home connection.

What is ping?

In simple terms

Ping sends a small "are you there?" packet to a host and waits for the host to send it back. If the answer arrives, the host is reachable over the network and you learn how long the trip there and back took, the round-trip time (RTT). If no answer arrives, either the packet was lost, the host is down, or something along the way is configured not to answer.

Technical background

Ping uses the Internet Control Message Protocol (ICMP), defined for IPv4 in RFC 792. The sender transmits an Echo Request (ICMP type 8) carrying an identifier, a sequence number and some payload. A host that supports it answers with an Echo Reply (type 0) that copies the identifier, sequence number and payload. The sender matches replies to requests by sequence number and measures the time between sending and receiving.

Several values come out of that exchange:

• RTT — time from sending the request to receiving the reply. It includes propagation delay (distance), serialization on each link, queuing in routers and the time the target takes to generate the reply.
• TTL — every IP packet carries a Time To Live counter that each router decrements by one. The reply arrives with whatever is left of the TTL the target started with.
• Packet loss — requests that never got a reply within the wait time.
• Jitter — how much the RTT changes from one reply to the next.

ICMP is handled by the operating system kernel, not by an application, so a successful ping proves that the IP stack answers, not that the web server, database or mail service on that host is working. Equally, ICMP is often deprioritized or filtered, so a failed ping does not prove that those services are down.

Why use ping?

• Basic reachability. Confirms that a public IP address or hostname answers at the network layer at all.
• Latency baseline. Shows the round-trip time from a fixed point on the internet, which helps you notice when latency to a server suddenly doubles.
• Packet loss. Missing replies point at congestion, a faulty link or rate limiting, and tell you whether to look deeper with Traceroute or MTR.
• DNS sanity check. The result shows which IP address the hostname resolved to on our server, which catches stale or wrong A records.
• Outside-in view. When something works from inside your network but customers complain, a ping from outside shows whether the host is reachable from the internet.

Who should use it?

• System administrators checking whether a server answers after a reboot, migration or firewall change.
• Network engineers collecting a quick latency and loss baseline before running longer path tests.
• DevOps and SRE teams confirming that a load balancer or public endpoint is reachable from outside their cloud.
• Support staff who need a neutral second opinion when a customer reports that "the site is down".

How ping works

The general flow is always the same: resolve the name, send echo requests, collect echo replies, compute statistics. The NetTools.tech implementation adds strict limits around that flow:

1. Input validation. The host field accepts a hostname or a public IP address. A pasted URL such as https://example.com/path is reduced to the host name. The count must be a whole number from 1 to 10.
2. Resolution and address check on the server. The hostname is resolved on the NetTools server. If any of the returned addresses is private, loopback, link-local or reserved, the request is refused, so a public name cannot be pointed at an internal network. When a name has both IPv4 and IPv6 addresses, the IPv4 address is used. IPv6 targets are refused because the probe server has no IPv6 connectivity yet.
3. Fixed binary, no shell. The server runs the system ping binary by absolute path with a fixed argument list. Only the validated IP address and the count come from your input. The command is equivalent to:

ping -n -c 4 -i 0.5 -W 2 -w 7 -- 203.0.113.10

That means: numeric output, the chosen number of requests, one request every 0.5 seconds, wait up to 2 seconds for each reply, and stop after the count plus 3 seconds at the latest.

4. Parsing. The output is parsed into individual replies (sequence number, TTL, time) and the transmitted/received summary. Min, average and max RTT and the jitter value are calculated from the replies.
5. Limits. Each client has a request budget (ping costs a small share of it), at most 30 pings per target address per 10 minutes are accepted across all users, and the whole server runs at most 4 probe processes at the same time. If it is busy, you get a "try again in a few seconds" message instead of a queued request.

The probes leave from the NetTools.tech server in Latvia, so every number describes the path from there to the target.

How to use the NetTools.tech ping

1. Open the Ping tool.
2. In Host, enter a hostname or public IP address, for example example.com or 1.1.1.1. You can also click one of the example chips under the form.
3. Optionally change Count, the number of echo requests (1–10, default 4). More requests give a better loss and jitter picture but take a few seconds longer.
4. Select Run Ping. Results appear within a few seconds.
5. Use Copy to paste the output into a ticket or chat.

The same test is available in the web terminal as /ping example.com or /ping 1.1.1.1 --count 2.

Understanding the results

The result consists of a table with one row per reply, a status line and a summary.

The resolved IP in the status line is worth a glance every time. If it is not the address you expect, the problem may be DNS rather than the network.

Example: checking a web server after a firewall change

An administrator has changed the firewall in front of a web server and wants to confirm that it still answers from the internet. The values below are illustrative and use documentation addresses (the real tool refuses documentation ranges as targets).

Input: Host example.com, Count 4.

Status: 203.0.113.10: 4 sent, 4 received, 0% loss min / avg / max: 38.1 ms / 41.9 ms / 52.7 ms, Jitter: 9.8 ms

Reading it: the host answers every request, the baseline RTT is about 38 ms and one reply took 14 ms longer, which raised the jitter figure. With only four samples, a single slow reply has a large effect. The host is reachable at the IP layer; the next step is a Port Check on 443 to confirm the web service itself is reachable through the new rules.

Common use cases

• Verifying that a server answers after a reboot, failover or IP change.
• Checking whether a hostname resolves to the expected public IP address from outside your network.
• Getting a latency figure to a customer's server before a migration, and comparing it afterwards.
• Separating "unreachable" from "slow" when users report problems, before running MTR.
• Confirming that a provider's network is answering when your own connection is suspect.

Troubleshooting

100% packet loss, but the website loads

The host or a firewall in front of it drops ICMP. This is very common for cloud servers with default security groups and for corporate firewalls. Check the service directly: a Port Check on port 443 or an HTTP Status Checker request tells you whether the application is reachable.

Partial loss, for example 1 of 10 lost

A single lost reply can be ICMP rate limiting on the target or a router, or brief congestion. Run the test again with 10 requests. If the loss persists, run MTR to see whether loss starts at a particular hop and continues to the destination.

"resolves to a private or reserved address"

The hostname has at least one A or AAAA record in a private or reserved range, so the tool will not contact it. This is intentional. Check your DNS records with DNS Lookup; internal names should not be published in public DNS unless that is deliberate.

"has no IPv4 address" or an IPv6 error

The target is IPv6-only, or you entered an IPv6 address. The probe server cannot test IPv6 yet. Use a dual-stack hostname or test the IPv4 address.

"This target has been tested many times"

The per-target budget (30 pings per 10 minutes across all users) is exhausted. Wait a few minutes. The budget exists because every probe is visible to the target's operator.

RTT is much higher than expected

Look at the path. A Traceroute shows whether traffic takes a detour, for example via another continent. Remember that the measurement starts in Latvia; a server in another region will naturally show a higher RTT than it does from nearby.

Common mistakes

• Treating no reply as "down". ICMP filtering is a configuration choice, not a failure.
• Comparing our RTT with yours. The two pings start from different places and take different routes.
• Drawing conclusions from one or two packets. Use the maximum count of 10 when loss or variation matters.
• Pasting a full URL with a port. Ping tests a host, not a port. Use Port Check for host:port questions.
• Ignoring the resolved IP. If the address is wrong, you are testing the wrong machine.

Limitations

• The test runs from one location, the NetTools.tech server in Latvia. It cannot tell you how the host behaves from your network or from other continents.
• Only IPv4 is supported at the moment; IPv6 addresses and IPv6-only names are refused.
• At most 10 echo requests per run, with a fixed 0.5-second interval and packet size. It is a snapshot, not monitoring.
• ICMP may be rate-limited or deprioritized by routers and hosts, so RTT and loss can look worse than real application traffic experiences.
• Ping proves that the IP stack answers. It says nothing about whether a specific service, certificate or application works.
• The TTL value is a rough hint only; it cannot reliably identify an operating system or the exact hop count.

Security & privacy

• What is sent: only the hostname or IP address you enter and the count. The ping itself is sent by the NetTools server to that target, so the target's operator sees our server's address, not yours.
• What is refused: private, loopback, link-local, multicast and reserved addresses, and hostnames that resolve to any of them. This protects internal infrastructure, including ours.
• No shell: the server executes a fixed binary with a fixed argument list; nothing you type is interpreted as a command.
• Rate limits: per-client limits, per-target limits and a global cap on concurrent probes prevent the tool from being used for flooding.
• What not to enter: there is nothing sensitive to enter. Only test hosts you are entitled to probe, and avoid putting internal hostnames into any public tool.

Related tools

• Traceroute — shows the hop-by-hop path to the same host. Guide: Traceroute guide.
• MTR — repeated probes to every hop, for loss and latency per router. Guide: MTR guide.
• Network Jitter Test — longer stability measurement from your browser or our server. Guide: jitter test guide.
• Port Check — tests whether a TCP service accepts connections when ICMP is blocked. Guide: port check guide.
• Is It Down? — checks whether a website answers over HTTP(S).
• Overview of all diagnostics: Network diagnostics guide.

Summary

Ping sends ICMP echo requests and reports whether replies come back, how long they take and how many are lost. The NetTools.tech version sends 1 to 10 requests from our server in Latvia to a public IPv4 target, with strict validation and rate limits. Use it for a quick reachability and latency check, and confirm with a port or HTTP check whenever ICMP is filtered.