The site that always complains, and never has evidence
It is four hundred miles from anyone who could look at it. It has no local IT. Everything you monitor about it, you monitor from somewhere else, which means you are measuring the path to it, not the experience on it.
The pattern is familiar. Users report that things are slow, intermittently, usually in the morning. Your central monitoring shows the site reachable with normal latency. The circuit provider reports no faults. Somebody eventually drives out, finds nothing, and the ticket is closed until it reopens a fortnight later.
The gap is structural rather than a failure of effort. A probe from your data centre to that site measures your path to the site. It does not and cannot measure the site's path to anything else, and it is completely blind to the local network everyone there shares.
One vantage point, on the floor, permanently
An agent at the site measures outward, continuously, from the same position as the people complaining. It runs on whatever you have: an existing server, a thin client, or a Raspberry Pi taped behind a monitor, since builds go down to ARMv7.
Small hardware is often the more honest option. A board plugged into the same access switch as the users experiences the same VLAN, the same wireless, the same congested uplink at nine in the morning.
And because it keeps measuring while the circuit is down, spooling to disk and delivering the backlog afterwards, the outage itself is recorded rather than appearing as a hole in the graph.
Install, realistically
- 01
Add the agent in the portal and download the install pack for that platform.
- 02
Someone on site runs one installer script. No console access, no configuration file to edit, no key to type in; the credential is already inside the pack.
- 03
It appears in the portal and starts taking whichever tests you assign it. Updates are requested centrally afterwards.
The pack is single-use and expires in a day, so one that goes astray is not a standing liability.
The local checks are the ones nothing else can do
Path measurement to your applications is the obvious half. The half that surprises people is what an agent can see about the network in the room.
- Path Health to head office and to the applications that matter
- Continuous per-hop loss, latency and jitter with the route fingerprinted every pass, so a reroute at the carrier is an event with a timestamp rather than something inferred later from two graphs that both look odd.
- DHCP
- An exhausted scope or a rogue server is a site-wide outage that looks like nothing at all from the outside. Every remote probe you own will report the site perfectly healthy while nobody can get an address.
- ARP sweep and LLDP
- What is actually on this segment, and what the switch says it is. A changed gateway MAC is either a planned failover or something you very much want to know about.
- WiFi scan
- Signal, channel occupancy and neighbouring networks from where the users sit. The most common "the network is slow" at a branch is a channel that three other tenants also chose.
- DNS and HTTP
- Resolution from the resolver this site actually uses, and application timing broken out by phase. A site pointed at a dead secondary resolver is slow in a way no central test reproduces.
- Path MTU
- Deliberate black-hole detection. Small packets work, so everything appears up, and anything substantial hangs, the classic aftermath of a tunnel change nobody documented.
What the next complaint looks like
Before
Users report slowness. Nothing you monitor shows a fault. The provider finds nothing. It happens again in two weeks.
After
You open the site, scrub to the reported window, and see per-hop loss beginning at the third hop inside the provider network, with the healthy hops beyond it ruled out.
The call
You give them a timestamp, an address and a duration, from a vantage point that was measuring throughout. That is a different conversation from "our users say it is slow".
Start with the site that has cost you the most time
One branch is slow. Other sites are fine.
An illustrative investigation. Follow the evidence from where it was measured to the result you need to explain.
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 point2.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 checks3.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