Probes

A probe is a monitoring agent that executes checks on behalf of the platform. Probes are geographically distributed — they run in different cities and countries so that each check result reflects the experience from that location, not just from a single central point.

Kinds of probes

Platform probes cover major regions worldwide. Private probes let you monitor services that are not reachable from the public internet — internal APIs, private Kubernetes services, or staging environments — from inside your own network.

How a probe connects

Each probe holds a single persistent WebSocket connection to the UptimeHunt broker (wss://app.uptimehunt.io/v1/agent). The broker pushes the probe's configuration (the list of services and check parameters) down this link. The probe runs its schedule locally and pushes results back up the same connection.

This design means:

• No inbound ports — the probe only makes outbound connections.
• Resilience to central downtime — the probe keeps running on its local schedule even if it loses the broker connection, buffering results and replaying them (with their original timestamps) once reconnected.
• Fast config delivery — when you add or change a service, the broker pushes the updated config to all connected probes within seconds.

What a probe reports

For each check execution, the probe sends:

• A checking signal the instant it starts (so the dashboard can show "pending" in real time).
• A result frame when the check completes, carrying the full check result including timestamp, reachability, response time, and type-specific data.

Results are durably buffered on the probe's local disk (SQLite) so they survive process restarts and network outages. The buffer is bounded to prevent unbounded disk usage; see Self-Hosted Probes for configuration details.

Probe health

The platform continuously monitors probe connectivity. The Settings → Probes table shows a connection badge for each probe, based on when it last contacted the broker:

• Online — contacted the broker within the last few minutes.
• Offline — no recent contact (its checks are not currently running).
• Never connected — registered but has never established a link.

This connection status is distinct from the per-probe check health (healthy / slow / error / stale) shown on the Dashboard fleet map, which is derived from the actual check results each probe is producing. Platform probes are visible to everyone; your private probes appear only to members of the organization that owns them.

Multi-probe monitoring

When more than one probe is assigned to a service, each probe runs the check independently on its own schedule. This gives you:

• Geographic redundancy — a single-probe outage does not look like a service outage.
• Location-specific data — you can see that a service is reachable from Europe but not from North America, pointing to a routing or CDN issue rather than a full outage.
• Consensus-based alerting — the alert engine can be configured to require failures from multiple locations before opening an incident, reducing false positives from transient single-probe network issues.

Private / self-hosted probes

You can run your own prober inside your infrastructure. See Self-Hosted Probes for installation and configuration instructions.

Kubernetes auto-discovery

The Kubernetes autodiscovery operator pairs probes with your cluster's Ingress resources — it watches for new hostnames and automatically creates services for them. See Kubernetes Auto-Discovery.

Related

• Checks — what probes execute and record
• Self-Hosted Probes — running your own probe
• Global Probe Network — the platform's built-in probe fleet
• API: Probes — probe management via the API