You install one binary. Everything else is ours to run.

There is no collector tier to size, no database to stand up and nothing to keep patched. The decisions that matter to you are where to measure from and what to measure, which is the point, because those are the two decisions that determine whether the data is any good.

An application feels slow

An illustrative investigation. Follow the evidence from where it was measured to the result you need to explain.

Branch officeApplication endpoint

1.Measure from the affected location

Place an agent where the problem is experienced. Compare the same target from another vantage point to see whether the issue is local or shared.

Set up a vantage point

2.Separate the path from the application

Use Path Health for the route and HTTP for request timing. Compare DNS, connection, TLS and response phases before deciding which layer to investigate.

Choose your checks

3.Inspect the moment that matters

Choose the time window, inspect individual results and read the trust qualifiers. Keep the target and vantage point alongside the evidence.

Read the results

What actually happens

01
You choose where to measure from
One agent per vantage point: a branch office, a rack, a VM in each cloud region, the site where people are complaining. Where you measure from is part of what the measurement means.
02
It measures whether or not it can reach us
Results are written to the agent host first and shipped second. A network problem between you and us delays delivery; it does not lose the data describing the problem.
03
Context arrives on its own
Hop 7 stops being an IP address and becomes a named network in a known city, and the several addresses belonging to one device are recognised as one device. You did not have to label anything.
04
You ask questions of it
Every measurement stays queryable, not just the averages. The interesting question during an incident is almost always about one specific bad minute rather than the hour containing it.

A measurement of a broken network has to survive the broken network

The moment your monitoring is most valuable is the moment its connection back to the platform is most likely to be degraded. A system that ships results straight from memory loses precisely the data covering the outage it exists to explain, and you find out when you go looking for it.

So the agent writes every result to the host's own disk first and ships from there. A partition delays delivery. It does not lose data. When the link returns, the backlog drains in order and the gap in your dashboard fills itself in.

The same property makes restarts and upgrades uneventful. There is nothing in flight that exists only in a running process, which is why upgrading the fleet is not a change window.

While the link is down

Probes: keep running on schedule
Results: accumulate on local disk
Shipping: retries with backoff, in order
On recovery: backlog drains, gap fills in
Data lost: none, until the disk budget is full

We can ask an agent to measure. We cannot ask it to do anything else.

Running someone else's software on your network is a serious thing to agree to, so the limit is enforced by the software rather than promised in a policy document. This is the section to send to whoever reviews that decision.

Anything dangerous is decided on your host

Running a command, skipping certificate checks, using elevated privilege: each is enabled locally by whoever administers that machine. There is no remote switch, so a compromise of our control plane cannot turn your fleet into a way to run code inside your network.

An agent cannot invent work for itself

Results are accepted only for tests that already exist. An agent reporting something nobody configured is refused rather than stored.

Credentials belong to one agent

Each agent gets its own identity. Removing one does not disturb the others, and one compromised host does not become a fleet-wide problem.

It runs with the least privilege that works

And when it lacks a privilege, the measurement is marked with what was lost rather than quietly falling back to a worse method that looks the same on a graph.

One service, and it updates itself

On your side there is one agent per location. It installs as a system service, starts at boot, and can be upgraded across the whole fleet from the portal without touching the hosts.

There is no collector to size, no database to run, no message queue to keep healthy and no retention job to babysit. That machinery exists (measuring a network properly is not a small problem) but operating it is our job, and the reason it is worth paying somebody for is that it stops being your on-call rotation.

If it cannot be our job, because the data is not allowed to leave, the same system runs inside your environment as a deployment we certify and support.

Your operational burden

To install: Unpack, run one script
To connect: Nothing; it registers itself
To upgrade: Select agents, apply
To scale: Install another agent
To operate: Nothing else

Detail for investigations, trends for years

Individual measurements and long-term summaries are kept side by side, with their own retention periods. Dashboards read the summaries, so a year-long view is fast. An investigation reads the measurements, so the specific ninety seconds you care about is still there in full.

Most platforms average on arrival and keep only the summary. It is cheaper and it works perfectly until somebody asks what happened at 03:14 three weeks ago, at which point the answer has been averaged into a flat hourly figure and no amount of querying will recover it.

How long each is kept is a plan setting rather than something compiled in, so lengthening it later is a decision rather than a migration.

Book a demo Read the documentation