> ## Documentation Index
> Fetch the complete documentation index at: https://pulse-41cf5b0d.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Private Probes for Internal Network Monitoring

> Deploy a private probe inside your network to monitor internal services, staging environments, and hosts behind firewalls — no inbound ports required.

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:

| Check type       | Description                                                                                                                              |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **HTTP / HTTPS** | Full HTTP request with configurable method, headers, and body. Validates status code, response time, and optional response assertions.   |
| **TCP port**     | Opens a raw TCP connection to `host:port` and measures connect latency. Useful for databases, message brokers, and any non-HTTP service. |
| **PING**         | Tests reachability of a hostname via a TCP connection probe and measures round-trip latency.                                             |

<Note>
  SSL, DNS, Browser (Puppeteer), WebSocket, BGP, and other advanced monitor types are executed by PulseGuard's edge workers and are not currently dispatched to private probes.
</Note>

## 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:

| Plan           | Private probes |
| -------------- | -------------- |
| **Free**       | Not available  |
| **Pro**        | Up to 3 probes |
| **Enterprise** | Unlimited      |

<Info>
  Upgrading your plan is available from Dashboard → Settings → Billing.
</Info>

## Next steps

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

<Card title="Deploy a Private Probe with Docker" icon="docker" href="/probes/setup">
  Run the PulseGuard probe container in your network in under 5 minutes.
</Card>