---
title: Ping, Traceroute & MTR: network troubleshooting basics
description: When something's slow or unreachable, three classic tools tell you whether it's you, the network, or them. Here's how ping, traceroute and MTR work — and when to reach for each.
canonical: https://watchfor.io/blog/ping-traceroute-mtr
---

# Ping, Traceroute & MTR: network troubleshooting basics

2026-05-02 · WatchFor Team · Networking · networking, debugging, basics

When something's slow or unreachable, three classic tools tell you whether it's you, the network, or them. Here's how ping, traceroute and MTR work — and when to reach for each.

"The site is slow." Three words that launch a thousand support tickets — and the first question is always the same: *is it us, the network in between, or them?*

Three classic tools answer exactly that, and they've been around for decades because they work: **ping**, **traceroute**, and the one that combines them, **MTR**. Knowing how to read them turns "it's slow, I dunno why" into "hop 6, the transit provider, is dropping packets." Let's learn them.

## Ping: is it alive, and how far?

**Ping** is the simplest network tool. It sends a small packet to a host and times how long the reply takes. It answers two questions:

- **Reachability** — does the host respond at all?
- **Round-trip time (RTT)** — how many milliseconds there and back?

```
ping example.com
64 bytes from 192.0.2.10: time=24.3 ms
```

What to read:

| You see | It means |
| --- | --- |
| Fast, steady replies | Healthy connection |
| High RTT | Latency — far away or congested |
| Some replies missing | **Packet loss** — unstable link |
| No replies at all | Unreachable, or blocking ping |

Ping tells you *that* there's a problem and roughly how bad — but not *where* it is. For that, you trace the route.

## Traceroute: where does it go (and break)?

**Traceroute** maps the **path** your packets take to reach a host — every router ("hop") along the way, with the latency to each:

```
1  router.local      1 ms
2  isp-gateway        8 ms
3  transit-provider  22 ms
4  ...               45 ms
5  ...              210 ms   ← jumps here
6  example.com       60 ms
```

The skill is reading the pattern, not the individual numbers:

- **Latency that rises and *stays* high** from a certain hop onward → the problem likely started there.
- A **single high hop** that goes back down → often harmless (some routers de-prioritise replying to traceroute, but still forward traffic fine).
- The trace **stops** at a hop → packets may be dying there (or that hop just doesn't reply).

> **Don't panic at one slow hop.** Routers often answer traceroute slowly while forwarding real traffic perfectly. What matters is high latency or loss that *persists* across the following hops.

## MTR: the best of both, live

**MTR** ("My TraceRoute") combines ping and traceroute and runs them **continuously**. Instead of a single snapshot, it shows every hop with live, rolling stats — latency *and* packet loss per hop, updating in real time.

That's a big deal, because the most revealing network problems are **intermittent**. A one-off traceroute might look fine; MTR running for a minute reveals the hop that drops 20% of packets only sometimes. It's the tool the pros reach for when a problem won't sit still.

## Which tool, when?

| Question | Tool |
| --- | --- |
| Is the host up? How's the latency? | **Ping** |
| *Where* along the path is it slow or broken? | **Traceroute** |
| Is there *intermittent* loss/latency, and where? | **MTR** |

A typical flow: ping to confirm there's a problem → traceroute to locate it → MTR to watch a flaky hop over time.

## From one-off command to always-on

These tools are perfect for *diagnosing* a problem you already know about. But you don't want to be running them by hand to *discover* one. That's where monitoring comes in: continuous ping checks catch reachability and packet-loss problems automatically, and a continuous network-path (MTR-style) monitor watches the whole route so you see a bad hop the moment it appears — not when a customer complains.

## The bottom line

| Tool | Answers | Reach for it when… |
| --- | --- | --- |
| **Ping** | Up? How fast? | You need a quick health/latency check |
| **Traceroute** | Where's the problem? | You need to locate it along the path |
| **MTR** | Where, and how often? | The problem is intermittent |

Master these three and "the network is weird" becomes a question you can actually answer. They turn a vague slowdown into a specific hop with a specific problem — which is the whole battle.

Try them without installing anything: the free [ping](/ping-test) and [traceroute](/traceroute-online) tools. For always-on coverage, see [network monitoring](/docs/monitors/network).

---

Canonical page: https://watchfor.io/blog/ping-traceroute-mtr · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt