Most network tools agree on what to measure. The differences are in how.

Loss, latency, jitter, per-hop. Every vendor's feature list says the same words. What separates them is whether the numbers underneath survive contact with a real network, one with load balancers, rate-limited routers and asymmetric return paths.

These pages are the technical argument for RouteSpear, in more detail than a feature table allows. They are here because the differences are not marketing distinctions, they change what the numbers on your screen mean, and whether the hop your tool is blaming is the hop that is actually at fault.

If you are evaluating us against something else, these are the questions worth asking of both.

Start with path discovery Compare approaches

A path, not a splice of several

On supported transports, RouteSpear keeps each trace on a consistent flow. Stable flows support route-change comparisons, while a rotating explorer samples other branches. UDP and ICMP transports can overlap hop waits; TCP remains sequential within a flow. Each result records its transport and flow-control limits.

Paris-style flow control, with stable flows and an explorer

Loss that is not loss

A router that declines to answer a probe looks identical to a router dropping your traffic, and most tools paint both bright red. RouteSpear checks whether the traffic arrived downstream, and if it did, says so on the hop instead of raising an alarm about a router doing its job.

Five confidence verdicts, on every hop, every window

Measuring through the outage

A monitoring system that goes quiet when the network breaks has gone quiet at the only moment anyone needed it. Agents keep measuring while cut off, write to a bounded log on disk, and deliver the backlog when the path clears.

Enrolment happens on the first successful push, not at startup

Limits your control plane cannot raise

You are installing software with raw socket access on machines inside your network. The probe ceilings, the target policy and the dangerous capabilities are all fixed on the agent command line, and nothing served from our servers can widen them.

Signed configuration, agent-local grants, built-in deny list

Logs, only when it matters.

Investigate the incident without continuously ingesting the full application log stream.

Keep routine logs on your hosts. Choose which unhealthy agents or tests trigger a bounded, redacted capture from an agent or remote SSH host. The excerpt attaches to the incident, ready for the investigation.

How targeted log capture works

Read the evidence before the verdict.

Explore three illustrative situations. These examples explain the method; they are not live measurements.

A hop stays silentThe uplink breaksTraffic takes another route

AgentNo probe replyResponding

What was observed

An intermediate hop does not answer, while the destination still responds.

What to check next

Inspect downstream evidence and the confidence verdict before treating a missing reply as traffic loss.

Read the confidence model

Four decisions that shaped everything else

These are not aspirations on a wall. Each one costs something (storage, complexity, or the ability to show a confident number where a competitor would) and each is visible in what the product does when the measurement gets hard.

Show the confidence; do not round it up: Every measurement carries how it was taken: the transport, how much control the agent had over the flow identifier, the smallest interval the clock could distinguish. A probe that fell back to a coarser method says so on the row rather than being averaged in as though it had not.
A silent hop is a fact, not an absence: Plenty of routers are configured never to generate ICMP. A hop that does not answer is recorded at its position with no address, because "hop 6 is silent" and "there is no hop 6" are different claims, and collapsing them shifts every hop behind it.
Keep the samples, not just the averages: Aggregating on ingest is cheaper and works right up until the question is about a specific ninety seconds three weeks ago. Rollups are built alongside the measurements rather than instead of them: dashboards read the rollups because they are fast, investigations read the measurements because they are still there.
Refuse to answer rather than guess: Where the arithmetic does not support a number (a per-link delay that comes out negative because the return paths differ), the result is marked indeterminate. A plausible-looking figure that nobody can defend is worse than an admission.

What we will not claim

A vendor page that lists only strengths is not describing a measurement system. These are real constraints of the physics and the protocols, and RouteSpear surfaces each one rather than papering over it.

ICMP cannot reliably see fan-out

ICMP carries no ports, and most load balancers hash on ports. Varying the flow identifier correctly still often produces probes that travel together, so a width of one from an ICMP test means we could not look, not that the path does not fork. The product says exactly that, on the result, and points you at a TCP-based test.

Per-hop RTT is not link latency

Every figure is a cumulative round trip from the agent, and the return path from hop seven need not be the return path from hop eight. Subtracting one from the other goes negative on real networks. Link delays are derived from distributions and marked indeterminate when the arithmetic does not hold.

A confidence score is not a probability

The score exists to rank hops for attention. Its weights are engineering judgement, not parameters fitted against a ground-truth dataset, because no such dataset exists for this problem. It is presented as a ranking and never as a percentage likelihood.

Point it at a path you already argue about

The fastest way to judge any of this is to run it against a route that has already caused you a bad week.

Book a demo Read the quickstart