Private Probes for Internal Network Monitoring

Private probes let you bring PulseGuard’s monitoring capabilities inside your own infrastructure. Instead of relying solely on PulseGuard’s public edge network, you deploy a lightweight Docker container in any environment you control — a private data centre, a VPC, an on-premises server, or a staging cluster — and that container performs checks on your behalf, reporting results back to your dashboard in real time.

​

What private probes are

A private probe is a Docker-based agent you run on your own infrastructure. The pulseguard/probe image packages a minimal Node.js runtime and the same check primitives (@pulseguard/core) used by PulseGuard’s global edge network. Once the container is running, it registers itself with PulseGuard, receives check assignments, executes them locally, and streams results back — all without you configuring any additional servers, load balancers, or ingress rules.

​

Why you need them

PulseGuard’s public probes can only reach services that are accessible from the public internet. Private probes fill the gap for everything that isn’t:

• Internal APIs and microservices that live behind a corporate firewall or VPN
• Staging and QA environments that are intentionally kept off the public internet
• Databases and TCP services on private subnets you want to verify are reachable from within the network
• On-premises hosts in air-gapped or restricted environments where exposing an inbound port is not possible

With a private probe, you get the same uptime history, alerting, and status-page integration for internal services as you do for public ones.

​

How they work

Private probes use a poll-based architecture. The probe container initiates all connections outbound — it never listens on any port. Here is the lifecycle for each check cycle:

1. Register — on startup, the probe authenticates with PulseGuard using your probe token and registers itself against your account.
2. Poll — on every poll interval, the probe requests a batch of pending check jobs assigned to its region.
3. Execute — the probe runs each check locally (HTTP/HTTPS requests or TCP connection attempts) and collects the results.
4. Report — results are sent back to PulseGuard in a single batch so they appear in your monitor history immediately.
5. Heartbeat — independently of the poll loop, the probe sends a periodic signal to PulseGuard so your dashboard can confirm the agent is alive.

Because the probe only makes outbound HTTPS connections to worker.pulseguard.io, you do not need to open any inbound firewall rules or configure NAT port-forwarding.

​

Supported check types

A private probe can perform the following checks against targets inside your network:

​

Probe registration

When the probe container starts, it reads your PULSEGUARD_PROBE_TOKEN and calls the PulseGuard worker to register itself. Registration records the probe’s region label and links it to your account. From that point on, any monitor you configure to use your private probe’s region label will have its check jobs dispatched to that container on the next poll interval. You can register multiple probes under the same account — for example, one per data-centre region or one per isolated network segment. Each probe appears separately in your dashboard with its own connectivity status and last-heartbeat timestamp.

​

Probe tiers

The number of private probes you can register depends on your plan:

​

Next steps

Ready to deploy your first probe? Follow the step-by-step Docker setup guide.