To test packet loss, send a bounded number of probes to a known destination and calculate (probes sent − replies received) ÷ probes sent × 100. For example, 20 ICMP echo requests with 19 replies yield 5% unanswered echoes in that sample. That is an ICMP test result, not proof that 5% of application traffic was lost. Confirm the symptom from other locations and with the affected application's traffic before assigning a cause.
Run a bounded ping test
On Linux with iputils ping, replace the example hostname with the endpoint you are authorized to test:
ping -c 20 -i 1 -w 25 target.example.com
-c 20 caps the number of echo requests, -i 1 spaces them one second apart, and -w 25 caps total runtime at 25 seconds. If the deadline expires before all 20 are sent, calculate from the actual transmitted and received counts in the summary, not the requested count. Use -4 or -6 when comparing a specific IPv4 or IPv6 path. The iputils manual defines these options and describes ICMP echo requests and replies.
On Windows Command Prompt or PowerShell, the comparable bounded command is:
ping /n 20 /w 1000 target.example.com
Here /n sets the request count and /w is the per-reply wait in milliseconds, not a total command deadline. Windows also supports /4 and /6. Do not use the continuous /t mode for a bounded check. These are the current Microsoft ping options.
Record the source host and network, resolved destination address, address family, start time and timezone, sent/received counts, and round-trip-time range. A hostname resolving to different addresses across runs may change the path. If name resolution fails, no echo test reached the target; investigate DNS separately before interpreting it as packet loss. If every echo goes unanswered, the host or network may block or deprioritize ICMP even while the application works. RFC 2680 treats packet-loss measurement as specific to a declared probe type, source, destination, and loss timeout.
One clean short test does not rule out intermittent loss. One missing response does not identify the failing link. Repeat a small, bounded test during the reported symptom and compare it with a known-good interval; avoid flood-ping or rapidly increasing probe size and rate on a live network.
Compare endpoints and vantage points
Test from the client network that sees the problem and, if authorized, from a second location. A useful sequence is the local gateway, a controlled endpoint beyond the local network, and the affected service endpoint. Keep the address family and test window consistent. If only a Wi-Fi client sees failures while a wired client on the same site does not, inspect wireless signal, roaming, access-point counters, and local interference before blaming the WAN. If both paths degrade only toward one service, inspect that service's edge and upstream path.
The direction matters. A round-trip echo result includes an outbound request and a return reply; it cannot, by itself, tell which direction lost a packet. A server-to-client test may use a different route and is useful corroboration, not a mirror image of the client-to-server path. Network paths and traffic treatment can also differ between ICMP and the application's TCP or UDP packets. Prefer a low-rate application health check or normal request observations to establish user impact; do not replay state-changing requests just to create test traffic.
If the problem occurs only under load, an idle ping may miss it. Compare tests during similar traffic conditions and check whether the application's own timeout, retry, and error rates rise in the same interval. Do not assign a universal “acceptable loss” percentage: a useful threshold depends on the application, protocol, sample size, baseline, and service objective.
Use MTR to investigate the path, not convict a hop
On a Linux system with MTR installed, a bounded report is:
mtr -r -c 20 target.example.com
-r produces a report and -c 20 limits its cycles, according to the MTR manual. MTR sends probes toward successive hops; run it only at a rate and from a source permitted by your network policy. Its hop list is a diagnostic view, not a guaranteed record of every packet's path.
Focus first on the destination row and the application symptom. A single intermediate hop can show unanswered probes while later hops and the destination answer normally. Routers may limit or deprioritize ICMP responses addressed to themselves without dropping forwarded traffic; router requirements permit ICMP error rate limiting. Do not open a provider fault for that hop alone. Loss beginning at one hop and persisting through the destination is stronger evidence of a path problem, but still needs repeat tests and endpoint or interface corroboration. Load balancing, route changes, and the return path can complicate localization.
On Windows, pathping combines route discovery with repeated probes, but its defaults can send many probes and take a while. Use its documented /q, /p, and /w controls only after deciding the probe volume and target are appropriate. Microsoft notes that a router's own unanswered probes need not mean it fails to forward traffic.
Use iperf3 only between authorized endpoints
When you control both ends and need to test a traffic type closer to the application, iperf3 can measure UDP datagram loss reported by its receiver. It creates real network load, so obtain approval, choose an owned test server, set a modest rate, and keep the run short. For an illustrative one-megabit-per-second, ten-second test:
iperf3 -c owned-test-server.example.com -u -b 1M -t 10
-u selects UDP, -b sets the offered bitrate, and -t limits duration in the iperf3 documentation. The sample rate is an example, not a universally safe setting; choose a rate below the approved test budget. Do not aim iperf3 at a public endpoint or launch a server exposed to the internet for this check. The server must be running and reachable before the client command can work.
This tests the iperf3 flow between those two hosts, not the application's exact protocol, route, packet size, or user experience. A TCP iperf3 throughput result is not itself a packet-loss percentage. Comparing upload and download requires separate authorized direction-specific tests; one direction's result cannot establish the other.
Corroborate the result with passive evidence
Read interface error and drop counters at the client, switch or access point, edge, and server where available. Compare deltas over the same time window rather than treating a lifetime counter as a current incident. A local receive drop can reflect host queue pressure rather than a cable or WAN fault. TCP retransmissions can support a transport-level diagnosis, but a retransmission alone does not prove where the original packet or acknowledgment was lost. Examine application timeouts and retries, load balancer results, and network-device events alongside the probe data.
Ask three questions before changing anything:
- Did an endpoint-to-endpoint test show a repeatable problem during the user's symptom?
- Do a second source or passive counters point to the same segment, direction, and time?
- Does the affected application show failed or delayed operations, rather than only missing ICMP replies?
If the answers conflict, preserve the measurements and narrow the test scope. A clean endpoint ping alongside failed application requests suggests investigating the application's protocol, service, firewall policy, or dependency rather than declaring the network healthy. A failed ping with healthy application requests suggests ICMP handling may differ. Configuration, route, wireless, or capacity changes should follow an identified fault and an approved change process, not a single probe result.
Keep application and network log evidence together
Network devices and applications may emit useful events about interface errors, connection resets, timeouts, or failed requests. Their fields and completeness depend on the source and collector. A centralized log service can help compare those events within a bounded time window, but it cannot replace active probes, interface counters, or packet-level measurements. See how to read logs for a structured investigation sequence and log management best practices for collection and data-handling safeguards.
Fluxtail is a paid Starter/Pro logs-focused service. If relevant network and application logs are already delivered through a supported receiver and mapped, its search, filters, and Live Tail can help inspect the retained events. It does not run ping, MTR, or iperf3; measure packet loss; or provide native network metrics or packet-loss alerts. Start with the probe and endpoint evidence, then use the available logs to test a specific hypothesis.