Monitoring Services Inside Your LAN with Private Probes
Most uptime services check your site from their cloud. That works perfectly for anything with a public address — and not at all for the half of your infrastructure that lives on a private network: the internal Postgres replica, the office NAS, the staging box on 10.0.x.x, the printer that the whole floor depends on. A cloud probe simply can’t route to 192.168.1.50.
The usual workarounds are ugly: punch a hole in the firewall, expose the service to the internet, or stand up a second monitoring stack just for the LAN. Private probes avoid all three.
What a private probe is
A private probe is a tiny agent you run inside your own network — a container, a Raspberry Pi, a spare VM, anything that can reach the targets you care about. It opens an outbound connection to PingZen and runs the checks locally, then reports results back. Nothing inbound is exposed; the probe reaches out, not the other way around.
From your dashboard, a monitor assigned to a private probe looks exactly like any other monitor — same protocols, same charts, same alerts — except the check originates from your LAN instead of the cloud.
What you can finally watch
- Internal databases — Postgres, MySQL, Redis on RFC1918 addresses.
- NAS and storage — SMB/HTTP health of a Synology or TrueNAS box.
- Intranet web apps — staging environments, internal dashboards, wikis.
- Network gear — routers, switches, and access points by ICMP or TCP.
- Anything air-gapped from the public internet but reachable on your LAN.
Setting one up
- On the PRO plan or above, open the probes section and generate a private probe API key (
pz_...). - Run the probe agent on a host inside the network — a single container is the simplest path.
- Wait for the probe to show online in your dashboard.
- Create or edit a monitor and assign it to that probe.
One detail worth knowing: a single monitor’s probe set must be all-public or all-private, not a mix. Under the default aggregation rule a public probe can never reach an internal address, so it would vote DOWN forever and produce false alerts. Keep internal monitors on private probes and public monitors on the cloud fleet. You can still run several private probes across different sites — office plus a cloud VPC, for example — for high availability.
Why this beats exposing the service
Exposing an internal service to the internet just so a cloud probe can reach it trades an availability problem for a security one. A private probe keeps the service exactly where it belongs and still gives you a single pane of glass for both your public site and your internal infrastructure.
Want to watch what’s behind your firewall? Read the private probes guide or learn more about LAN monitoring.