Remote probes and quorum

A probe is a small headless Docker container you run on a machine you already own. It connects outbound over HTTPS to your own Vigil controller, asks for work, runs the checks it is given, and reports what it measured. Assign a monitor to two or three of them and require agreement before an incident opens.

Vigil hosts nothing. There is no Vigil region, no relay, no managed probe and nothing to subscribe to. If you have no machine in Asia, Vigil cannot give you a probe in Asia. That is a different product shape from every hosted monitoring service, and it cuts both ways: you get vantage points a vendor will never sell you, and you get none at all until you put one somewhere.

Why bother

A single-vantage monitor cannot tell "the target is down" from "the path between my one server and the target is down". That is the false positive every operator has been paged by, and the reason they eventually stop trusting the alerts.

With three probes and a majority rule, one broken route is reported as degraded, the probe that disagreed is named, and nobody is woken up. All three agreeing is an outage, and it opens exactly one incident.

The rules you choose

Plus a minimum number of probes that must have answered before any conclusion is drawn at all.

A probe that did not answer is never counted as a failure. Not in any mode, at any threshold. If fewer probes answer than the minimum, the round reports "no conclusion" and the monitor goes to unknown, which opens no incident, sends no alert and starts no recovery action. A fleet on a laptop that closed must never look like the internet going down, and that is the single behavior the whole feature is arranged around.

Installing one

Create the probe in the app, copy the command it gives you, run it. The token in it is single use and expires in an hour; the agent trades it for a long-lived credential and stores that on a volume.

docker run -d --name vigil-probe --restart unless-stopped \
  -v vigil-probe-state:/var/lib/vigil-probe \
  -e VIGIL_CONTROLLER_URL=https://vigil.example.com \
  -e VIGIL_PROBE_ENROLLMENT_TOKEN=vgpe_... \
  your-registry/vigil-probe:1.14.0

Nothing inbound. The agent opens no listening socket, so there is no port to forward and no NAT to traverse. It works from an office LAN, a home connection or a laptop with no network change at all. On the probe's side you allow outbound 443 to your controller, and that is the whole firewall change.

What it costs to store

Probe data is the largest thing Vigil writes, so it is bounded by two retention windows you control: the raw per-probe rows for 14 days and the round with its decision for 90. A round where every probe agreed the target was up is dropped early, because the observation it produced is already recorded where uptime and reports read from.

Measured on one machine, a twenty-monitor installation on a 60 second interval with three probes reaches about 0.95 GB and stops there. The formula, the measurement and the caveats are in the repository you buy, not only in this sentence.

What this is not

• Not hosted locations. Every probe runs on hardware you pay for. There is no Vigil network and no per-region price.
• Not a verified location. The location field says what you typed. Vigil cannot see the machine.
• Not independent if it is not independent. Two agents on one host share a kernel, a NIC and a default route. The app warns you where you assign them; it does not stop you.
• Not high availability. Probes make the measurement distributed. The controller is still one server.

The full operator manual, including reverse-proxy requirements, rotation, revocation, rollback, capacity and troubleshooting, ships in the repository as docs/REMOTE-PROBES.md. How this compares to hosted services is on the comparison page, where every competitor cell cites the vendor's own documentation and the date it was read.