Traceroute Hops Analyzer

Introduction

Traceroute output records how probes behaved at each visible hop between a source and a destination. The useful signal is not just the last line. A mid-path timeout, a sudden round-trip time jump, and packet loss that continues to the destination point to different follow-up checks.

Traceroute Hops Analyzer turns pasted Unix traceroute, Windows tracert, tracepath-like, and MTR report rows into a structured path brief. It extracts numbered hops, host labels, average round-trip time (RTT), hop-to-hop delay changes, timeout rows, loss percentages, and a final-hop status so the same raw terminal text can become a ticket-ready summary.

The destination field is a label for the brief and exports. The page does not run traceroute, ping the host, or test reachability from the server. It analyzes the text you paste or the local text file you select, so the result describes that captured sample and not the live path at the moment you read the page.

TXT, LOG, and OUT-style text files are read in the browser session, with a one-megabyte size limit. Copied CSV, downloaded DOCX, chart images, and JSON exports can still contain private hostnames, internal addresses, and service names from the original trace, so treat those artifacts like any other network diagnostic evidence.

Technical Details:

Traceroute-style tools work by sending probes with limited hop counts and waiting for intermediate routers or the destination to answer. When a hop limit expires, an Internet Control Message Protocol (ICMP) time-exceeded reply can reveal the router that handled that probe. Different systems use different probe types and wording, which is why Unix traceroute, Windows tracert, and MTR reports need slightly different parsing.

The analyzer reads numbered rows and ignores unrelated text such as headers and completion lines. Standard traceroute rows are reduced to hop number, host text, returned probe times, asterisk count, timeout wording, average RTT, and inferred partial loss. MTR rows are read from their report columns, including Loss%, Snt, Last, Avg, Best, Wrst, and StDev.

Rule Core

Calculation Core

The two configurable gates are intentionally simple. Latency jump threshold flags a responding hop when its average RTT rises by at least that many milliseconds compared with the previous responding hop. Loss threshold flags MTR loss, final-hop loss, and partial traceroute rows when the percentage meets or exceeds the configured value.

A row with only asterisks or explicit timeout wording is treated as no reply. If later hops respond, that timeout is described as an intermediate no-reply rather than proof that forwarding stopped. If the final parsed hop is also a timeout row, the brief treats the trace as stopped before a destination response.

The Hop Delay Step Profile chart plots average RTT as a line and hop-to-hop step as bars, with the latency gate drawn as a reference line. Chart exports use the same parsed rows as the tables and JSON, so the visual should match the evidence ledger instead of introducing a separate interpretation.

Everyday Use & Decision Guide:

Use the analyzer when a ticket, chat thread, customer report, or incident timeline contains route output that needs a cleaner read. It is most useful when you need to decide whether to rerun the test, compare another path, attach concise evidence to an escalation, or stop blaming an intermediate timeout that does not carry through to the destination.

Set the gates to match the network being reviewed. A low latency jump threshold can make sense on a LAN, inside a data center, or across a short VPN path. A higher threshold is more practical for internet, WAN, and transoceanic routes where geography and carrier handoffs naturally add delay.

• Use Destination as a report label. It keeps exports understandable but does not drive a live lookup or probe.
• Use Latency jump threshold to decide when a hop-to-hop RTT increase becomes ticket evidence.
• Use Loss threshold to separate incidental probe loss from loss patterns that deserve a longer MTR or provider check.
• Use Normalize after copying from terminals, web consoles, or tickets that added mixed line endings or trailing spaces.
• Use the built-in traceroute, tracert, and MTR samples when you need to confirm how each output family is parsed.

Final-hop evidence should carry more weight than intermediate probe behavior. Many routers forward production traffic in hardware but answer diagnostic probes through a control plane that may be rate-limited, filtered, or deprioritized. Loss or high RTT that appears only at one middle hop and disappears later is weaker evidence than the same pattern repeated through the destination row.

For intermittent incidents, one short trace rarely settles the case. Capture during the symptom window, repeat from the same client and another network when possible, and compare traceroute evidence with ping, TCP checks, application logs, and provider maintenance notes before closing an escalation.

Step-by-Step Guide:

Work from source text quality to summary findings, then export only after the parsed rows match the route sample you meant to review.

1. Enter a Destination label such as a hostname, IP address, ticket ID, or service name.
2. Set Latency jump threshold in milliseconds. Start lower for local paths and higher for WAN or internet paths.
3. Set Loss threshold as a percentage. Keep it strict when destination loss matters, and loosen it only when you intentionally want to ignore minor probe noise.
4. Paste one traceroute, tracert, tracepath-like, or MTR report sample, or browse for a local text file under one megabyte.
5. Click Normalize if the pasted text has uneven spacing or line endings. Unrecognized lines are ignored, so keep the numbered hop rows intact.
6. Read Path Snapshot first for parser profile, hop count, largest latency step, worst average RTT, loss review, and final state.
7. Open Escalation Findings for severity, hop span, evidence, and suggested next check.
8. Use Hop Evidence Ledger when you need row-level proof of a timeout, latency step, private hop, or loss pattern.
9. Use the delay chart, CSV, DOCX, image, or JSON exports after the parsed evidence is credible enough to share.

Interpreting Results:

The headline separates a steady path from a sample with threshold findings. Traceroute Path Looks Steady means no parsed timeout, jump, or loss row crossed the configured gates. Traceroute Escalation Brief means the findings table has at least one row to review.

The largest latency step is not always the root cause. It marks where the measured response time increased between two visible responding hops. Asymmetric routing, load balancing, ICMP handling, reverse-path delay, and private carrier networks can all shift the apparent step away from the device or link that users feel.

JSON is the most complete export because it keeps thresholds, summary values, parsed hop objects, table rows, findings, and chart rows together. Use CSV or DOCX when the recipient needs a human-readable table, and use the chart image when a latency step needs to be shown quickly in an incident note.

Worked Examples:

Unix traceroute sample with one large delay step

The built-in traceroute sample has five parsed hops. Hop 1 sits near 1.2 ms, hop 2 near 3.9 ms, and hop 3 near 42.1 ms. With the default 25 ms latency jump threshold, the hop 2 to hop 3 increase becomes a finding because the step is roughly 38 ms. Hop 4 shows * * *, but hop 5 responds near 48 ms, so the timeout is read as an intermediate no-reply rather than a stopped path.

Windows tracert sample with the same path shape

The Windows sample uses Request timed out. instead of a Unix-only asterisk row, and it prints times such as <1 ms. The parser still extracts numbered hops, returned probe times, and the timeout row. That lets a Windows support capture and a Unix support capture land in the same Path Snapshot and Hop Evidence Ledger structure.

MTR report with isolated middle-hop loss

The MTR sample includes a transit hop with 5.0% loss and a later row marked 100.0% with no usable timing, followed by a destination row that responds. With the default 20% loss gate, the 5.0% row is below the gate. The no-reply row is still worth noting, but downstream response prevents it from becoming destination-loss proof.

Final-hop loss during an incident

If the destination row itself crosses the loss gate, the reading changes. A middle-hop timeout can be a router choosing not to answer probes, but final-hop loss means the target row did not receive or answer enough probes in that sample. Capture a longer MTR, preserve the timestamp, and compare from another source before handing the case to a provider or service owner.

FAQ:

Glossary:

Hop

A visible step in the route output, usually a router or endpoint that replied to a limited-hop probe.

RTT

Round-trip time, measured in milliseconds, from sending a probe to receiving a response.

TTL or hop limit

The packet field that limits how far a probe can travel before a router may return a time-exceeded response.

MTR

A diagnostic report format that combines route-path probing with repeated latency and loss measurements per hop.

Asterisk row

A traceroute row where one or more probes received no visible reply.

Latency step

The increase in average RTT between one responding hop and the next responding hop.

Final-hop loss

Packet loss reported or inferred on the destination row, which is usually stronger evidence than isolated middle-hop loss.

References:

• RFC 792: Internet Control Message Protocol, IETF, September 1981.
• traceroute(8) Linux manual page, Michael Kerrisk, man-pages project.
• How to properly interpret a traceroute or MTR, APNIC Blog, March 28, 2022.
• mtr(8) manual page, Arch Linux manual pages.