Locations

Yorker runs checks from 14 hosted locations distributed across six continents. You can also run checks from private locations inside your own infrastructure.

Hosted locations

Every hosted location runs on Fly.io infrastructure in the corresponding region. Checks execute close to your users, giving you realistic latency measurements from each geography.

Using locations in config

Specify locations as an array of location IDs in your monitor configuration:

monitors:
  - name: Homepage
    type: http
    url: https://example.com
    locations:
      - loc_us_east
      - loc_eu_central
      - loc_ap_northeast

When a check runs, it executes independently from each configured location. A check with 3 locations and a 5-minute frequency produces 3 results every 5 minutes — one per location.

You can also set default locations for all monitors:

defaults:
  locations:
    - loc_us_east
    - loc_eu_central

monitors:
  - name: Homepage
    type: http
    url: https://example.com
    # Inherits loc_us_east and loc_eu_central from defaults

  - name: APAC Health
    type: http
    url: https://example.com
    locations:
      - loc_ap_southeast
      - loc_ap_northeast
    # Overrides defaults with APAC locations

Plan limits

The number of locations you can use depends on your plan:

Paid and enterprise plans have access to all 14 hosted locations. The free tier is limited to 3 locations per check. See Pricing for current plan details.

Private locations

Private locations let you run Yorker's runner inside your own infrastructure — behind a firewall, in a VPC, or on-premises. This is useful for monitoring internal services that are not publicly accessible.

How they work

1. You deploy the Yorker runner container in your infrastructure (Docker, Kubernetes, or a VM), typically using the Docker snippet that yorker locations create prints for you.
2. The runner polls the Yorker control plane over outbound HTTPS for check assignments. No inbound ports needed.
3. The runner executes checks against your internal services — HTTP requests, browser sessions, and MCP tool calls all originate from inside your network, so internal hosts stay private.
4. The runner submits each check result (timing, assertions, Web Vitals, certificates, and screenshot references for browser checks) to the Yorker control plane via POST /api/runner/results. This drives alerts, SLOs, insights, and the dashboard — it is mandatory.
5. For browser checks the runner also emits OTLP metrics and traces directly to your collector. For HTTP and MCP checks, runner-direct OTLP emission is opt-in: set OTLP_ENDPOINT and OTLP_API_KEY as environment variables on the runner container at startup and the persistent-http agent will emit OTLP for every check it runs.
6. The control plane evaluates the result (alerts, SLO burn, baselines, insights). If a team OTLP endpoint is configured, it also enqueues OTel events — synthetics.check.completed, alert state changes, SLO warnings, certificate events, insights — in an outbox that the orchestrator polls and ships to your collector asynchronously. If no OTLP endpoint is configured, the enqueue is skipped entirely (results still power the dashboard and alerting, there are just no outbound OTel events).

Key properties

• Outbound-only — The runner initiates all connections. No firewall rules, no VPN tunnels, no inbound ports.
• Internal targets stay private — The runner calls your internal services from inside your network, so you never have to expose a staging API or intranet dashboard on the public internet to monitor it.
• You can keep per-check OTLP inside your network — Point OTLP_ENDPOINT on the runner container at an internal collector and the per-check metrics/traces/logs emitted by your private agent never leave your infrastructure. Check results still flow to the Yorker control plane over outbound HTTPS; derived events (alerts, SLO, insights, check.completed) still flow through the orchestrator outbox on the way to your collector.
• Same runner image — Private locations use the same runner container as hosted locations. No separate software to maintain.
• Discounted runs — Private browser runs are billed at 50% of the hosted rate.

Setting one up

See the Private Locations guide for a complete step-by-step walkthrough (create the location, generate a runner key, deploy the agent, verify health, and assign the location to monitors).

You can drive the same flow from the CLI:

# Create a private location (also auto-provisions an initial runner key and prints a Docker snippet)
yorker locations create --name hq-data-center --display-name "HQ Data Center"

# List private locations only (default)
yorker locations list

# Include hosted locations in the list too
yorker locations list --all

# Create another runner key for an existing location (secret is shown once)
yorker locations keys create loc_abcdef123456 --name "eu-west-1"

# List runner keys on a location (prefixes only)
yorker locations keys list loc_abcdef123456

# Revoke a key by its ID
yorker locations keys revoke loc_abcdef123456 rkey_abc123

# Delete a private location (also revokes all its runner keys)
yorker locations delete loc_abcdef123456

Once the runner is online, reference the private location ID in any monitor:

monitors:
  - name: Internal API
    type: http
    url: https://internal-api.staging.local/health
    locations:
      - loc_abcdef123456
      - loc_us_east  # Can mix private and hosted locations