MTR — Traceroute and Ping Combined, Continuously
MTR runs a traceroute repeatedly and accumulates statistics for each hop, producing a continuously updating table of loss and latency along the whole path. That combination is what makes it far more diagnostic than either tool alone: a single traceroute gives one sample per hop, which is not enough to distinguish a real problem from noise.
Why run it
Because it resolves traceroute's central ambiguity. A hop showing high loss in a single traceroute usually means nothing — many routers deprioritise generating responses about themselves while forwarding traffic perfectly. The distinguishing signal is whether the loss continues at every subsequent hop. Loss at one hop that disappears further along is a router deprioritising responses; loss that starts at a hop and persists to the destination is a genuinely broken link. Only repeated sampling makes that distinction visible.
Why automate it
MTR is already continuous within a run, and running it on a schedule extends the same logic outward: the problems worth catching are the ones that appear at certain times or degrade over weeks. It is also the most persuasive evidence available when the faulty link belongs to a transit provider — a sustained record of loss beginning at a specific hop is considerably harder to dismiss than a screenshot of one bad run, and getting someone else to fix their network is usually the actual task.
What it gives you
The tool that turns "somewhere between us and them" into a specific link, with enough data behind it to make the case. It is the highest-yield network diagnostic on this list for problems that are not at either endpoint.