Traceroute Hops Analyzer

{{ badge.label }}: {{ badge.value }}

Traceroute or MTR output:

Paste one capture with numbered hop rows; headers may remain and unrecognized lines are ignored.

{{ fileStatus || 'Drop one traceroute, tracert, MTR TXT, LOG, or OUT file onto the textarea.' }}

Source format:

Auto detect reports both the requested and resolved format in the result.

Destination label:

Use a hostname, IP address, service name, or incident label.

Latency jump:

{{ formatNumber(jump_threshold_ms, 1) }} ms

Lower values suit short private paths; higher values reduce noise on WAN and VPN paths.

Loss threshold:

{{ formatNumber(loss_threshold_pct, 1) }} %

A finding owns the boundary: loss equal to the selected gate is flagged when it is above zero.

Visible hop rows:

Keep an unusually long route ledger readable without changing the diagnosis.

rows

Measure	Value	Interpretation	Copy
{{ row.label }}	{{ row.value }}	{{ row.context }}

Finding	Severity	Evidence	Suggested next check	Copy
{{ row.name }}	{{ row.severity }}	{{ row.evidence }}	{{ row.next_check }}

Showing {{ report.visible_hop_count }} of {{ report.hop_count }} parsed hops. Exports include all hops; increase the Advanced row limit to inspect more.
Hop	Host	Average RTT	Step	Loss	Interpretation	Copy
{{ row.hop }}	{{ row.host }}	{{ row.average }}	{{ row.delta }}	{{ row.loss }}	{{ row.interpretation }}

A route trace records which network hops answered a series of probes from one source at one moment. It is useful when a service feels slow, a destination is unreachable from one network, or an incident needs evidence about where delay first appears. It is not a map of every router that forwarded the traffic, because devices can forward packets without returning diagnostic replies.

Common route-trace patterns and their practical meaning
Observed pattern	Reasonable conclusion	What remains uncertain
One middle hop is silent; later hops answer	Forwarding continued beyond the silent hop	The router may filter or rate-limit replies
Round-trip time rises and stays high afterward	Added delay may begin near that point	The return path and queueing cause are unknown
Loss appears on one intermediate MTR row only	That hop deprioritized its own replies	Transit traffic may still be unaffected
Loss repeats downstream or reaches the destination	The evidence is more consistent with path impact	A longer capture and service test are still needed

Round-trip time (RTT) measures the journey from the source to a hop and back. It is not the one-way delay between adjacent routers. The difference between two responding rows is therefore a step in cumulative RTT, not a direct measurement of one link. Load balancing, asymmetric return paths, changing queues, and hostname lookups can all alter the picture between runs.

Traceroute and Windows tracert usually show a small set of timings or asterisks for each hop. My Traceroute (MTR) summarizes repeated probes with an average and loss percentage. Those formats support related but not identical evidence. A fair comparison keeps the source network, destination, probe method, run duration, and incident window as consistent as possible.

The destination remains the strongest point of reference. An intermediate timeout followed by later replies is weak evidence of failure, while final-row loss or a trace that stops before the target deserves more attention. Even then, confirm the actual application protocol because a firewall can handle User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), and Transmission Control Protocol (TCP) probes differently.

How to Use This Tool:

Start with one complete numbered capture from the affected source network.

Paste the capture into Traceroute or MTR output or load one TXT, LOG, or OUT file. Headers may remain; unrecognized lines are ignored.
Leave Source format on Auto detect for ordinary input. Pin Unix traceroute, Windows tracert, or MTR when ticket notes or mixed text cause the detected format to be wrong.
Set the Latency jump threshold and Loss threshold for the path being investigated. The defaults are 25 ms and 20%; lower jump gates suit short private routes, while higher gates reduce WAN or VPN noise.
Read the final state and escalation findings before focusing on a middle hop. If no numbered rows are recognized, paste an unwrapped capture in one supported format.

Interpreting Results:

A threshold finding says that the parsed evidence met a selected rule. It does not identify a faulty carrier or router. Give the most weight to a pattern that persists through later responding hops, reaches the final row, and repeats during the reported symptom.

A Latency step above gate needs a repeat trace or MTR. Escalate only when the added RTT persists downstream.
An intermediate No reply followed by a later response usually supports reply filtering, not a forwarding stop.
Loss carries downstream and Final-hop loss above gate are stronger than isolated intermediate loss, but a longer MTR and a real service check improve confidence.
A final no-reply row can reflect a short hop limit or blocked probes as well as a reachability problem. Test the destination separately.

Technical Details:

Only numbered hop rows from 1 through 256 enter the route model. Duplicate hop numbers keep the first recognized row. Auto detection chooses MTR when it finds a Loss% report shape, Windows tracert when Windows phrases are present, and Unix traceroute or tracepath otherwise.

Formula Core:

For traceroute and tracert rows, average RTT is the arithmetic mean of the returned probe times. A value printed as less than a threshold, such as “<1 ms,” is represented as half that threshold. MTR rows use the reported Avg column.

{\bar{t}}_{h} = \frac{\sum_{i = 1}^{n} t_{i}}{n}

For a short trace row, inferred probe loss is the share of explicit asterisks among returned timings plus asterisks. A full timeout row is 100% loss for that row. MTR loss uses the report's Loss% value.

L_{h} = \frac{m_{h}}{m_{h} + n_{h}} \times 100

Here, t is a returned probe time in milliseconds, n is the number of returned timings, and m is the number of missing probes. The hop-to-hop step subtracts the average of the previous responding hop from the current average; silent rows do not become the baseline.

Δ_{h} = {\bar{t}}_{h} - {\bar{t}}_{previous responding}

Rule Core:

Traceroute finding rules and boundary behavior
Finding	Exact rule	Severity treatment
Latency jump	Positive step ≥ jump gate	High when step ≥ max(2 × gate, gate + 50 ms); otherwise Medium
Loss flag	Loss > 0% and loss ≥ loss gate	High at final row, Medium when repeated downstream, otherwise Low
Intermediate no reply	No timing and a later hop responds	Low; forwarding clearly continued in the capture
Final no reply	The last parsed row has no timing	High; destination reachability still needs a separate check

Both gates own equality. A 25.0 ms positive step meets a 25.0 ms jump gate, and 10.0% loss meets a 10.0% loss gate. The extra loss > 0% condition prevents a zero gate from flagging zero-loss rows. A display limit from 5 to 256 shortens only the visible ledger; all parsed hops remain in findings and calculations.

Accuracy and Privacy Notes:

The capture and destination label are analyzed locally; entering a destination does not start a network request. Files are limited to 1 MiB, source text to 20,000 lines, and parsed routes to 256 unique hops.

Threshold severity is a deterministic triage heuristic, not a protocol diagnosis.
Short traces estimate loss from very few probes; MTR is usually better for intermittent symptoms.
Hostnames, private addresses, and incident labels can disclose network details. Redact them before sharing an export.

Worked Examples:

Silent middle hop with a healthy destination

A four-hop trace averages 1 ms at hop 1, 31 ms at hop 2, shows only asterisks at hop 3, and averages 35 ms at the destination. With a 25 ms jump gate and 20% loss gate, hop 2 gets a 30 ms jump finding. Hop 3 gets low-severity timeout and isolated-loss findings because hop 4 responds with 0% loss. Repeat the route to test whether the 30 ms step persists; do not blame hop 3 from its silence alone.

References:

RFC 5388, Information Model and XML Data Model for Traceroute Measurements, RFC Editor, December 2008.
How to properly interpret a traceroute or MTR, APNIC Blog, March 2022.
How to interpret traceroute timeout hops, Simplified Guide.
How to diagnose a network route with traceroute, Simplified Guide.