mtr: Combine ping and traceroute for Loss in CI
mtr probes every hop on the path repeatedly, showing per-hop packet loss and latency, so an intermittent network fault stops being invisible.
When connectivity is flaky rather than dead, a single ping or traceroute misses it. mtr keeps probing every hop and reports loss percentages, which is how you find the one router dropping packets.
What it does
mtr merges traceroute and ping: it discovers every hop to the destination, then continuously sends probes and tracks loss and latency for each hop. The output updates live, or with --report it runs a fixed number of cycles and prints a summary table.
Common usage
# non-interactive report, 10 cycles, numeric
mtr --report --report-cycles 10 -n db.internal
# use TCP probes to a specific port (passes firewalls)
mtr --report -n -T -P 443 api.example.comOptions
| Flag | What it does |
|---|---|
| --report | Run non-interactively and print a summary |
| --report-cycles <n> | Number of probe cycles in report mode |
| -n | Numeric output, skip reverse DNS |
| -T | Use TCP SYN probes instead of ICMP |
| -P <port> | Destination port for TCP/UDP probes |
| -c <n> | Probe count in interactive mode |
In CI
Use --report (with --report-cycles) so mtr runs a bounded number of cycles and exits instead of running interactively forever. Read the Loss% column: loss that starts at one hop and persists to the destination indicates that hop is dropping packets; loss at a single middle hop that clears afterward is usually that router deprioritizing ICMP, not a real fault.
Common errors in CI
High loss only on a middle hop with 0% at the destination is normal (rate-limited ICMP), not a problem. "mtr: Failure to start ... Operation not permitted" means it lacks raw-socket privileges; run as root or use TCP mode where permitted. "mtr: command not found" on slim images means installing mtr or mtr-tiny.