Understanding Private Locations

A private location is a monitoring probe you run on your own infrastructure. Instead of statusas checking your endpoint from one of its public regions, a container you control performs the check and reports the result back over an outbound connection.

This page explains the model — what a private location is and the trade-offs of using one. For the setup walkthrough, see the private location guide; for fields and the API surface, see the private location reference.

When a private location is the right tool

Public probes can only reach what's reachable from the public internet. Anything behind a firewall, on a VPC, or on an internal-only DNS name is invisible to them. A private location lives inside that network boundary and can reach those endpoints directly.

Concretely, reach for a private location when you need to monitor:

• Internal APIs and services behind a corporate firewall or VPC.
• Databases, message brokers, or other backing services that don't expose a public port.
• Services in a region statusas doesn't offer a public probe in.
• An endpoint where the path the request takes matters — e.g. a check from your production VPC validates the same network policy your app traffic depends on.

If your endpoint is already public and you only want geographic coverage, the public locations are simpler and cheaper to operate.

How the connection works

A private location is not an inbound port statusas calls into. The probe initiates everything:

1. You deploy the statusas probe container — typically ghcr.io/openstatushq/private-location:latest — somewhere inside the network that needs to be monitored.
2. The probe opens an outbound, authenticated connection to the statusas platform using the token issued when you created the location.
3. statusas dispatches the checks assigned to that location down the connection. The probe runs them against your internal endpoints and streams the results back.

The consequence is that you only need outbound network access from the probe to the statusas ingest endpoint, statusas-private-location.fly.dev, on port 443. No inbound firewall rules, no exposed ports, no reverse tunnel — the same shape as any other agent that calls home.

If you self-host statusas, point the probe at your own ingest server with the OPENSTATUS_INGEST_URL environment variable — see self-hosting statusas.

How it differs from a public location

A monitor can be assigned to public locations, private locations, or both. Public-and-private hybrids are useful when you want a public probe for SLA reporting and a private probe for in-network diagnostics on the same endpoint.

Trade-offs to know about

Running a private location moves operational responsibility to you. Plan for:

• Probe availability. If your probe host is down, statusas can't run checks from it. Treat the probe as part of your own infrastructure — restart policy, host monitoring, log retention.
• Token handling. The probe's token authenticates it as your workspace. Inject it as an environment variable, store it the same way you store other secrets, and rotate it if a host is decommissioned.
• Egress only. Because the connection is outbound, an egress firewall that blocks statusas-private-location.fly.dev:443 will silently stop the probe from running checks. The probe will appear "connected" briefly and then go quiet.

Next steps

• Set up a private location — step-by-step deployment of the Docker probe.
• Deploy a private probe on Cloudflare Containers — a serverless deployment pattern instead of a long-running container.
• Private location reference — fields, API surface, and supported operations.
• Probes and locations — how the terms "probe", "location", and "region" relate.