RouteWatch
Six offices, ten targets, one grid that names whose network is at fault.
Free right now — no account, no card
Preview
1 interface design, then a screenshot of it running. Drag, scroll or use the arrows.
Free while we’re in preview
Get RouteWatch
Six offices, ten targets, one grid that names whose network is at fault.
The Mac button is for Apple Silicon. On an older Intel Mac, get this one instead.
One file, both ways. Double-click it for the window. Run the same file from a command prompt with arguments and it behaves as the command-line tool, because the engine is inside it. Nothing else to download and nothing to keep beside it.
Early preview. The window has been built and run, but not yet on a real Windows PC or Mac, so expect rough edges. The engine underneath it is fully tested.
- One file — no installer
- Reaches only what you point it at
- Source code published below
Free while in preview. It isn’t signed yet, so Windows or macOS will ask you to confirm the first time you open it. At launch, RouteWatch is included in every plan along with the rest of the range.
Rows, columns, cells
A probe agent at each office measures TCP connect latency to the same list of targets and writes a JSON report. Collect those files however you already move files around, then routewatch matrix merges them into a grid: sites down the side, targets across the top.
The shape of the slowness is the answer. A slow row means that site’s own uplink. A slow column means the target itself, because everybody sees it. One hot cell means only the path between those two endpoints. routewatch decomposes the grid by Tukey median polish and names which of the three it is, in words, every time it prints one.
X is a measurement that was taken and failed. . is a measurement never taken at all. Those are kept apart deliberately.
The honest part
TCP connect, not ICMP, because raw sockets need root. Readings run higher than ping and aren’t comparable with it, and a server that’s slow to accept looks exactly like a slow link from here.
It can’t see which hop is slow either. There’s no traceroute and no per-hop timing, only the two ends. And a site that stops reporting is simply absent from the grid rather than marked failed, because collecting the files was never its job.
Reading on the job itself
- How to find out what is using your bandwidth Meter per host, not per application. "The browser used 40 GB" is not useful; "40 GB went to one video host"...
Advanced & technical details Command-line builds, source code, checksums and a recorded session — for developers and IT teams
A working command-line build of the probe and matrix engine: TCP connect latency with percentile statistics, a site-by-target grid, and a median-polish diagnosis that separates “this site is slow to everything” from “everyone is slow to this service”. It measures end to end, so it names the bad link rather than the bad hop; per-hop analysis is on the roadmap.
Naming status
Working name only — brand verdict **AVOID** (Very High). Collision: RouteWatch®. Rename completely.
What it draws on
Existing paid software whose best ideas shaped this program: GlassWire Premium, NetLimiter, PingPlotter Professional, NetWorx.
Command line
There is nothing extra to install. The program you download is the command-line tool as well: give it arguments instead of double-clicking it and it runs as one, with its output on your terminal. The standalone builds below are the same engine on its own, for machines where you would rather not ship a window at all.
routewatch 1.0.0 - multi-site latency matrix
USAGE
routewatch <command> [flags]
COMMANDS
probe Agent command: measure TCP connect latency to every target and
write this site's report file
matrix Merge every site's report into one grid (rows = reporting sites,
columns = targets) and say whether a SITE, a TARGET or a single
LINK is the problem
worst Rank the worst site->target links across all reports
help Show this help
WHY A MATRIX
One machine can only tell you that it is slow. Several vantage points
measuring the same targets can tell you WHOSE fault it is: a whole slow row
means that site's uplink, a whole slow column means the target itself, and a
single hot cell means the path between just those two.
TARGET LIST (JSON)
{
"targets": [
{"name": "dc-east", "addr": "10.0.0.10:443"},
{"name": "dc-west", "addr": "10.1.0.10:443"}
]
}
A bare JSON array of target objects is also accepted, and "target" works as
an alias for "addr".
EXAMPLES
routewatch probe --site hq --targets targets.json --out reports/hq.json
routewatch matrix reports/hq.json reports/branch.json
routewatch matrix --dir reports --metric p95
routewatch worst --dir reports --top 3 --json
Run "routewatch <command> --help" for per-command flags.Recorded from the shipped binary, not written by hand.
Source
Every file the program is built from:
console.go · console_test.go · guided.go · main.go
SHA-256 checksums · build instructions & scope notes · full build plan