{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
Include reply lines and the packet or RTT summary when available.
{{ fileStatus || 'Drop one TXT, LOG, or OUT file onto the textarea.' }}
Auto detect reports the resolved format; a pinned format bypasses detection.
Name the hostname, address, service, or ticket represented by this one ping run.
Set the acceptable loss ceiling for this path.
%
Flag uneven reply timing above this threshold.
ms
Use the latency budget that matters for this target or service.
ms
Keep a long continuous run readable without changing its diagnosis.
rows
MeasureValueInterpretationCopy
{{ row.label }}{{ row.value }}{{ row.context }}
FindingSeverityEvidenceSuggested next checkCopy
{{ row.name }}{{ row.severity }}{{ row.evidence }}{{ row.nextCheck }}
{{ chartError }}

No valid reply timings to plot. Include reply lines with RTT values.

SeqRTTTTLFlagSource lineCopy
{{ row.sequence }}{{ row.rttLabel }}{{ row.ttlLabel }}{{ row.flag }}{{ row.sourceLine }}

Showing {{ replyRows.length }} of {{ report.sample_count }} parsed replies. Increase the Advanced row limit to inspect more.

RTT bandRepliesShare (%)Copy
{{ row.label }}{{ row.count }}{{ row.percent.toFixed(1) }}%
Traceroute Hops Analyzer Parse traceroute, tracert or MTR output locally and compare hop delays with no-reply or downstream-loss patterns before escalating a route issue.
Network Throughput Calculator Estimate useful network throughput and transfer time from link capacity and RTT with TCP window, loss and packet-rate bottleneck checks.
WAN Latency Calculator Estimate WAN round-trip latency from route distance and path overhead to compare target headroom, dominant delays and serial application wait.
File Transfer Time Calculator Estimate file transfer time from size and sustained bandwidth while accounting for TCP limits, overhead, compression and a required finish window.

A ping log is a timed sample of Internet Control Message Protocol echo requests and replies. Each reply can carry a sequence number, round-trip time (RTT), and time-to-live value. The closing summary usually adds sent, received, and lost packet counts. Together, those lines help distinguish complete loss, occasional loss, consistently slow replies, and timing that swings from one reply to the next.

Evidence Question it answers Important limit
Packet loss How many probes did not return during this run? Filtering and rate limits can look like path failure.
RTT minimum, average, and maximum How fast were the best, typical, and slowest replies? An average can hide a small number of disruptive spikes.
Reply-to-reply change Did latency remain steady throughout the sample? A short run may miss intermittent queueing or wireless contention.
Sequence gaps Are expected reply numbers absent without a matching timeout? A copied excerpt may simply have omitted lines.

Context determines whether a number is acceptable. A local gateway should normally have a much smaller delay budget than a remote service, while interactive voice or shell work reacts more strongly to uneven timing than a bulk download. Comparing a gateway run with a run to the affected endpoint helps locate the first part of the path where loss or delay appears.

Round-trip measurements do not certify application health. A destination may answer echo requests while HTTPS, DNS, SSH, or another service fails. The reverse is also possible when a firewall blocks ICMP but permits the application protocol. Ping is a path clue that should be paired with a service-specific check and, when needed, a route trace.

The sample window matters as much as the target. Four clean replies cannot rule out a fault that occurs during peak traffic, roaming, VPN load, or brief congestion. Repeat the same test from the same source during the symptom window before comparing runs.

How to Use This Tool:

Analyze one continuous ping run at a time and choose limits that reflect the target being tested.

  1. Paste or load output from Linux, macOS/BSD, Windows, or a generic ping command. Include reply lines and the packet or RTT summary when available.
  2. Leave Source format on Auto detect unless an incomplete excerpt is ambiguous. A pinned format bypasses detection.
  3. Use Target label to identify the host, service, or ticket represented by the run. The label does not perform a network lookup.
  4. Set the Packet loss gate, Jitter gate, and High RTT gate to the limits that matter for this path. The default loss gate of 0% treats any reported loss as a finding.
  5. Review Health snapshot and Connectivity findings, then inspect flagged sequence numbers in the reply ledger. Increase Visible reply rows only when more on-screen evidence is needed.

Interpreting Results:

Loss becomes a finding only when the percentage is strictly greater than the selected loss gate. Adjacent-change jitter also uses a strict greater-than comparison. Individual replies at exactly the high-RTT gate are counted as high RTT because that boundary is inclusive.

  • A Stable result means parsed loss, jitter, and individual RTT values stayed within the chosen limits. It does not prove the service or route is healthy outside this sample.
  • A reported packet summary is preferred over counts inferred from parsed reply and timeout lines. The result identifies which source supplied the total.
  • When a summary reports packets but no RTT reply line can be parsed, treat the high-severity finding as a parsing or reachability question. Check the original log before concluding that every reply lacked timing.

Technical Details:

Linux, macOS/BSD, and Windows format reply and summary lines differently. Format detection looks for platform-specific reply and summary signatures, then the parser extracts timings, sequence numbers, TTL values, timeout lines, packet totals, and any reported RTT summary. Missing totals are inferred only from recognized reply and timeout rows.

Transformation Core:

  1. Normalize line endings, remove trailing whitespace, and resolve the requested source format.
  2. Parse up to 10,000 reply or timeout rows from no more than 20,000 source lines.
  3. Prefer reported packet and RTT summaries; otherwise calculate available values from parsed rows.
  4. Compare loss, adjacent-change jitter, individual RTT samples, and sequence gaps with the selected rules.

A value reported as less than a millisecond is represented by half of the printed upper bound, with a floor of 0.001 ms. That keeps the sample positive while acknowledging that the exact value was not printed.

Formula Core:

When the closing packet summary is absent, loss comes from parsed replies and timeouts. Jitter is the arithmetic mean of the absolute change between consecutive parsed RTT values.

L = NtimeoutNreply+Ntimeout×100% J = ∑i=2n|ri−ri−1|n−1

L is inferred packet loss in percent. J is adjacent-change jitter in milliseconds, r is a parsed RTT, and n is the number of reply samples. Jitter is unavailable with fewer than two replies. Population deviation is calculated from parsed RTTs when a Unix-style deviation is not reported.

Rule Core:

Finding Exact rule Severity rule
Packet loss Loss > selected loss gate High at 10% or more; otherwise Medium.
Adjacent-change jitter Jitter > selected jitter gate Medium.
High RTT Reply RTT ≥ selected RTT gate Medium for more than one sample; otherwise Low.
Sequence gap A number between the smallest and largest parsed sequence is absent Medium.

The chart groups parsed RTTs into fixed half-open bands: 0 to under 20 ms, 20 to under 50 ms, 50 to under 100 ms, 100 to under 200 ms, and 200 ms or more. These bands organize the sample; the selected RTT gate remains the actual diagnostic threshold.

Accuracy and Privacy Notes:

Ping text and loaded files are analyzed in the current browser. No probe is sent and the target label does not contact the named host.

  • Use a longer run captured during the symptom window for intermittent faults.
  • Keep source and destination, address family, packet size, interval, and network conditions consistent when comparing runs.
  • Confirm application reachability with its real protocol even when ping succeeds.

Worked Examples:

Remote spikes after a clean gateway

A gateway run shows 0% loss and tightly grouped RTTs, while a separate remote run reports 1% loss and several replies above a 120 ms gate. The second run supports investigating the wider path or remote endpoint. It does not identify the failing hop by itself, so the next useful evidence is a route trace and a service-specific test from the same host.

References: