Know which
hop changed,before the ticket says “the network is slow”.
RouteSpear measures the paths your traffic actually takes, from the vantage points that matter, and keeps enough context on every measurement to answer the next question without another investigation.
Free for up to 3 agents. No credit card.
Round-trip time to the same application. Is everyone affected?
The branch is slower. Compare its path around the change.
A different transit path. A measurable change.
- Branch RTT
- 24 → 86 ms
- HQ RTT
- 22 → 23 ms
The branch measures 86 ms to the application; headquarters measures 23 ms. Compare the two vantage points.
Most monitoring tells you that something is wrong. Almost none of it tells you where.
A ping graph with a step change in it is the beginning of an investigation, not the end of one. The next four hours go into reconstructing what the path looked like before, what it looks like now, and whose network the difference is in.
Endpoint checks lose the path
A synthetic check that fails tells you the far end is unreachable. It cannot tell you that the third hop started sending you through a different transit provider.
Traceroutes are not evidence
A traceroute you ran after the page is a snapshot of now. Without the one from before, you have nothing to compare it against.
Context arrives too late
Looking up who owns an address, and whether the path crossed a boundary, is manual work done under pressure at exactly the wrong moment.
Measurements that arrive already explained
Every row carries the path it took and the context needed to reason about it, so the common questions are lookups rather than investigations.
Hop-by-hop path health
Every probe records the full path, not just the endpoint. When latency moves, the hop that moved is already on the row.
Path change detection
Routes are fingerprinted on each pass. A reroute is an event with a before and an after, not something you infer from a graph.
AS and boundary context
Hops are stamped with origin AS, AS name, BGP prefix and reverse DNS, so "packet loss" becomes "loss entering AS3356".
Entity resolution
The same router seen from six agents under four addresses resolves to one device, with the evidence for why kept alongside.
Wi-Fi and floor-plan placement
Crowdsourced scans from the agents you already run turn into placements on your floor plans. No survey hardware.
Custom checks
Anything you can script can report through the same pipeline, with the same retention, promotion and dashboards.
Three moving parts, and you only install one of them
- 01
Deploy an agent
A single binary on Linux, Windows or macOS. Unpack it, run one script, and it registers itself and starts measuring. Nothing to type into the portal to connect the two.
- 02
It measures and ships
Results are written to the host disk first and shipped second, so a network problem between you and us delays delivery instead of losing the data describing it.
- 03
Context is added, then queried
Results are readable immediately, and hops stop being bare addresses as routing and identity context lands on them. Every measurement stays queryable, not just the averages.
Every vendor's feature list says loss, latency and jitter
The differences are underneath, in whether the numbers survive contact with load balancers, rate-limited routers and asymmetric return paths. These four pages are the technical argument, in more detail than a feature table allows.
A path, not a splice of several
On supported transports, each trace keeps a consistent flow. Stable flows track route changes while a rotating explorer samples other branches. The result records the paths observed and the limits of the method.
Loss that is not loss
A router declining to answer a probe looks identical to one dropping your traffic. We check whether the traffic arrived downstream before calling it loss.
Measuring through the outage
A tool that goes quiet when the network breaks went quiet at the only moment it mattered. Agents keep measuring while cut off and deliver the backlog afterwards.
Limits we cannot raise
Probe ceilings, target policy and dangerous capabilities are fixed on the agent command line. Nothing served from our control plane can widen them.
An agent on your network is a serious thing to ask for
So the boundaries are explicit, documented, and enforced by the software rather than by policy.
- Nothing dangerous is remotely triggerable
- Anything that could disrupt a network is configured on the agent host itself. The control plane can ask an agent to measure; it cannot ask it to do something the local operator has not already allowed.
- Least privilege, and it says so when it lacks it
- The agent runs unprivileged wherever it can. When it cannot get a capability, it reports the loss rather than silently degrading to a worse measurement.
- Measurements survive the network
- Results are written to a local spool before they are shipped. A partition delays delivery; it does not lose data.
- Your data stays queryable
- Every measurement can be opened in full, exactly as the agent reported it. There is no level of detail held back and no export step to reach it.
See it against your own network
A demo is a working stack and a conversation about your paths, not a slide deck. Thirty minutes.