Probes, Locations, and Regions

Reading the statusas docs, you'll hit three words that seem to mean the same thing — probe, location, and region. They don't. Each one names a different layer of the same system, and knowing which is which makes the rest of the configuration surface much easier to navigate.

The three terms in one sentence

A probe runs in a region and exposes itself to you as a location you can assign to a monitor.

That's the relationship in shorthand. The rest of this page unpacks each term and explains why the distinction matters when you're configuring monitors or debugging where a check came from.

Probe

A probe is the software that actually performs a check. It opens the TCP connection, sends the HTTP request, resolves the DNS record, measures the timing — and reports the result back. There are two kinds:

• Public probes. Operated by statusas: five hosts of our own (Vilnius, Kaunas, Warsaw, Frankfurt, Amsterdam) plus eight Cloudflare location hints. You don't manage them.
• Private probes. A container image (ghcr.io/statusas-lt/statusas-private-location:latest) you run on your own infrastructure. See Understanding Private Locations.

In day-to-day usage you rarely interact with the "probe" abstraction directly — you assign a location to a monitor, and the location decides which probe runs the check. The word matters mostly when you're reading debug output, opening a support ticket, or deploying a private location.

Region

A region is a physical-ish place where probes run. For statusas public probes a region is either one of our machines — vno (Vilnius), fra (Frankfurt) — or a Cloudflare location hint such as cf_weur (Western Europe), which is a broad area rather than a city.

A region is an attribute of a probe, not something you configure directly on a monitor. Two facts follow from that:

• The list of regions changes when statusas adds or removes capacity. The canonical list lives on the location reference page, which also documents the IPv4/IPv6 addresses you might need to allowlist.
• IP behaviour follows where the probe runs. Our own hosts have a fixed IPv4 and IPv6 address; Cloudflare regions have no static address at all. If you allowlist by IP, this matters.

Location

A location is what you assign to a monitor. It's the user-facing handle that points at one or more probes in a region. Two flavours:

• Public locations. One per public region. Selecting fra on a monitor means "run this check from a public probe in Frankfurt."
• Private locations. Created by you. A private location has a name, a token, and a set of attached monitors. The probe(s) you deploy with that token form the location.

When a monitor runs, the assigned locations determine where the check fans out to. Selecting three locations means three independent checks per cron tick — one per location — each contributing its own latency and status to the monitor's results.

Putting it together

Three quick scenarios make the distinction concrete:

• Adding global coverage. You attach vno, fra, and cf_oc locations to a monitor. Each one represents a public probe running in the matching Fly.io region. You don't pick a probe directly.
• Allowlisting on a firewall. You need IPs, which are a region attribute. Look them up in Location Reference. The location names like fra are the shorthand you'd grep for.
• Monitoring an internal API. No public region can reach your VPC, so you create a private location, deploy a private probe with its token, and pin the monitor to that location. The "region" is just wherever you happened to deploy the container.

Next steps

• Location reference — public locations, regions, providers, and the IPs to allowlist.
• Understanding private locations — when to run your own probe and the trade-offs.
• Create an uptime monitor — applies these concepts to a working monitor.