Two admins get the same “VoIP is choppy since Tuesday” ticket. One opens PingPlotter on the receptionist’s PC, leaves it tracing overnight, and next morning has a timeline graph showing loss starting at the ISP’s aggregation router every evening from 18:00. The other SSHes into the Linux jump host at the branch and runs mtr -r -c 600 against the SIP provider, getting a clean text table in ten minutes. Both used the same underlying technique — repeated per-hop probing — and both got useful answers. The difference is what kind of evidence they walk away with, how long it took, and where the tool could run.
At a glance
| PingPlotter | mtr | |
|---|---|---|
| Vendor / project | Pingman Tools | Open source (maintained by Roger Wolff; GitHub traviscross/mtr) |
| Licence | Commercial: Free, Standard, Professional, Cloud editions; subscription or perpetual | GPL |
| Price at time of writing | Standard from $6.99/mo, Professional from $29/mo, Cloud from $90/mo — check the vendor’s pricing page | No cost |
| Platforms | Windows, macOS; Cloud agents also on Linux | Linux, BSD, macOS; other Unix via source |
| Interface | GUI with trace graph and timeline | Curses TUI, plus report mode for text output |
| Default interval | 2.5 s | 1 s (below 1 s requires root) |
| Probe types | ICMP, UDP, TCP | ICMP, UDP (-u), TCP SYN (-T) |
| Long-term history | Yes — timeline, saved sessions (.pp2) |
No built-in history; you script and store output |
| Alerts | Yes in paid editions (email, sound, log, REST call, run program) | None |
| Export | Images, CSV, .pp2, shareable reports (paid) |
Text report, CSV (-C), JSON (-j) |
| Remote collection | Cloud edition | Run it wherever you have a shell |
| API | REST API in Cloud edition | None; parse CSV/JSON output |
| AS number per hop | Check current build | -z flag |
Where they genuinely differ
Time as a dimension
This is the big one. mtr gives you a snapshot — excellent statistics for the window you ran, nothing about the hour before. PingPlotter’s timeline lets you scroll back and see that loss appears at 18:00 and fades at 23:00, which is the story a support engineer at an ISP needs to hear. You can build history around mtr by running report mode from cron and storing the JSON, but then you’re maintaining a tool rather than using one.
The PingPlotter Free edition caps continuous monitoring at 10 minutes and drops the 1-second sample rate, so for overnight captures you need a paid edition or its trial (14 days for desktop editions at the time of writing).
Where it can run
mtr lives where admins already are: routers with a Linux shell, jump hosts, Linux servers, a Mac’s terminal via Homebrew. If the problem is between two data centres, mtr is almost certainly the faster start because it’s likely already packaged in the distribution.
PingPlotter is a desktop application for Windows and macOS. That’s ideal when the affected user is on a Windows PC and you want to trace from their exact vantage point, and less useful when the endpoint in question is a headless Linux VM — unless you’re on the Cloud tier with its Linux agent.
Evidence you can hand over
A PingPlotter graph with a marked time window is easy for a non-specialist to read, and the shareable report means you don’t have to explain how to open a proprietary file. mtr’s report table is the lingua franca of network engineers — most carrier NOCs recognise it immediately and some ask for it by name. For a technical escalation, a pair of mtr reports (one from each end) is often more persuasive than a screenshot; for a manager or an account rep, the graph wins.
Interpreting loss correctly
Both tools show the same trap: loss at an intermediate hop that doesn’t continue to the destination is usually a router rate-limiting ICMP replies, not dropped traffic. The mtr man page states this plainly. PingPlotter highlights loss prominently in red, which makes the trap more visible — useful if you know the rule, alarming if the person reading the graph doesn’t. Our guide to finding where packet loss really starts walks through the method for either tool.
Automation
mtr slots into scripts: mtr -r -w -j -c 300 target in a cron job or a monitoring check, output stored and parsed. PingPlotter’s automation leans on its alert actions (REST calls, launching a program) and, in the Cloud edition, a REST API. If your workflow is “run the same trace from 20 Linux boxes and collect the results”, mtr fits naturally. If it’s “watch one path and email me when loss exceeds 5% for two minutes”, PingPlotter does that without writing code.
Cost and procurement
mtr costs nothing and needs no approval beyond whatever your change process says about installing packages. PingPlotter needs a purchase, although the Standard tier is inexpensive and perpetual licences exist for shops that dislike subscriptions. Check the vendor’s current pricing page — tier limits (targets, devices, users) matter more than the headline price.
The verdict
Pick PingPlotter if…
- the problem is intermittent and you need hours or days of history on a timeline,
- you’re tracing from a Windows or macOS end-user machine,
- you want built-in alerting without scripting,
- the evidence will be read by people who don’t live in a terminal.
Pick mtr if…
- you need an answer in minutes from a Linux host, router shell or Mac,
- you’re sending results to a carrier NOC that expects a text report,
- you want to script traces across many hosts or feed results into your own monitoring,
- budget or procurement rules out a new licence.
Plenty of teams run both: mtr for the first ten minutes of triage, PingPlotter when the problem refuses to reproduce on demand and needs to be caught in the act. If you need continuous multi-site monitoring rather than on-demand traces, look at SmokePing vs Obkio.
Read the full PingPlotter review and mtr review, or browse other tools in Latency & Path Analysis. Get either from the vendor or project site only — see where to get tools safely — and note how we assess tools on the methodology page.