Probe a public service from Europe and Asia-Pacific

Let's consider a globally accessible public service at https://service.example.org/health. Customers use it from Europe and Asia-Pacific. You want to know whether it responds from both regions and whether request latency differs between their network paths.

Deploy one Worker in each region. Give each location its own Runner and HTTP Scenario. Both Workers connect outward to the same Urth control plane, assumed to run at https://urth.example.org. They probe the public service through their regional network paths.

flowchart TB
    EU["Worker in Europe"] -->|Public HTTPS path from Europe| Service["Globally accessible public service"]
    APAC["Worker in Asia-Pacific"] -->|Public HTTPS path from Asia-Pacific| Service
    EU -.->|Outbound API and broker connections| Urth["Urth control plane"]
    APAC -.->|Outbound API and broker connections| Urth

The solid arrows are probe traffic. The dotted arrows are control-plane connections. Scroll a diagram horizontally on a narrow screen to read all labels. Regional failures or slow responses can differ even when the control plane remains reachable.

Before you start

You need an Urth account and project, administrator access for Runner setup, urthctl, jq, and a Worker host in each region. Install the Workers using Installation. Configure both tools to use the default control-plane address; override it if necessary.

Replace the target URL below with a service you are authorized to test. Use a non-sensitive endpoint in an isolated evaluation environment while Urth remains an early preview.

1. Create or select the project

urthctl auth login
urthctl projects create global-service --use

For an existing project, use urthctl context use PROJECT instead of creating another one. Confirm the account and project before granting access.

2. Register one Runner for each location

Save this as runner-customer-eu.yaml:

apiVersion: urth.sre-norns.com/v1
kind: runners
metadata:
  name: customer-eu
  labels:
    location: customer-eu
spec:
  active: true
  description: Public service measurements from Europe
  jobRequirements:
    probeKinds: [http]
  workerRequirements: {}
  propagatedLabels:
    location: customer-eu

Create runner-customer-apac.yaml from the same definition. Change the name and both location values to customer-apac. Change the description to identify Asia-Pacific. Apply both files:

urthctl apply runner-customer-eu.yaml
urthctl apply runner-customer-apac.yaml

metadata.labels select the Runner for a Scenario. propagatedLabels carry the location into Results and Artifacts. jobRequirements.probeKinds: [http] permits HTTP jobs and requires admitted Workers to support that probe kind. Labels describe placement; they do not configure routes or prove physical location.

3. Authorize both Runners for the project

Run this for each Runner. Change customer-eu to customer-apac on the second pass:

URTH_LOCATION_RUNNER=customer-eu
urthctl apply - <<YAML
apiVersion: urth.sre-norns.com/v1
kind: runner-authorizations
metadata:
  name: ${URTH_LOCATION_RUNNER}
spec:
  runnerRef: $(urthctl get runner "$URTH_LOCATION_RUNNER" -o json | jq -r .metadata.uid)
  roles: [runner]
YAML

Confirm both grants:

urthctl runner-authorizations list

The grants permit this project's work on these channels. They do not grant access to the public service or deploy a Worker.

4. Enroll a Worker in each actual network location

Follow Obtain a private enrollment token file for each Runner. Transfer each token only to its intended host. Use a distinct installation key for each host. Follow the mutual TLS procedure if the broker requires client certificates.

On the Europe host:

install -d -m 700 "$HOME/.local/state/urth-worker/work"
urth-worker --name=customer-eu-worker \
  --working-directory="$HOME/.local/state/urth-worker/work" \
  --token-file /secure/path/customer-eu-token \
  --identity-key-file "$HOME/.local/state/urth-worker/worker.key"

On the Asia-Pacific host, use --name=customer-apac-worker and its own /secure/path/customer-apac-token file. The same key path is acceptable on a separate host; the key contents must differ. Supervise both processes using your deployment tool.

Each host needs DNS resolution, trusted HTTPS certificates, and an outbound route to the public target. It also needs outbound API and broker access. Test the public path from that host. Avoid a private route or proxy that changes the perspective you intend to measure.

Check the enrolled Workers:

urthctl get workers -l 'urth/runner.name=customer-eu'
urthctl get workers -l 'urth/runner.name=customer-apac'

5. Define one targeted Scenario per location

Save this as scenario-customer-eu.yaml:

apiVersion: urth.sre-norns.com/v1
kind: scenarios
metadata:
  name: service-http-eu
spec:
  active: true
  description: Public HTTP response from Europe
  requirements:
    matchLabels:
      location: customer-eu
  prob:
    kind: http
    timeout: 5s
    spec:
      target: https://service.example.org/health
      http:
        method: GET

Create scenario-customer-apac.yaml from the same definition. Change the name to service-http-apac, the location to customer-apac, and the description. Keep the target, request, timeout, and assertions equivalent. Apply both files:

urthctl apply scenario-customer-eu.yaml
urthctl apply scenario-customer-apac.yaml

flowchart TB
    Project["Project grants both Runners"] --> EUScenario["service-http-eu: location=customer-eu"]
    Project --> APACScenario["service-http-apac: location=customer-apac"]
    EUScenario -->|One Result| EURunner["Runner customer-eu"]
    APACScenario -->|One Result| APACRunner["Runner customer-apac"]
    EURunner -->|One Worker claims the job| EUWorker["Worker in Europe"]
    APACRunner -->|One Worker claims the job| APACWorker["Worker in Asia-Pacific"]

A Result selects one Runner and one Worker claims it. Additional Workers on a Runner share its jobs; they do not all execute each job. Separate targeted Scenarios ensure that you request a measurement from each required location. Keep materially different paths on separate Runners.

6. Run both checks and compare the evidence

urthctl trigger service-http-eu
urthctl trigger service-http-apac
urthctl get results service-http-eu
urthctl get results service-http-apac

Inspect each completed Result in the project's Runs view. Check the executor Runner and Worker, status, and available timing metrics or artifacts. Location labels also let you query each group:

urthctl get results -l 'location=customer-eu'
urthctl get results -l 'location=customer-apac'

Repeat the pair of manual triggers to gather comparable samples. Recurring execution is not implemented yet. Keep probe definitions, sample periods, and Worker load comparable.

If Europe succeeds while Asia-Pacific fails, inspect DNS, routes, TLS, and regional dependencies from the Asia-Pacific host. If both succeed but one is slower, compare the same timing metric. Total run time, DNS duration, connection time, and HTTP response time describe different things.

A regional Worker represents one controlled network path. It does not reproduce every customer's device, access network, or workload. Use these results with service telemetry and real user evidence. A missing run or unavailable Worker is a measurement gap, not proof that the public service is unavailable.

Add an internal perspective

Register an internal-vpc Runner using the same steps. Deploy its Worker inside the service's private network and authorize it for this project. Create a third Scenario with location: internal-vpc. For a direct comparison, use the same public URL. If you instead probe a private origin URL, record that difference: you are testing another endpoint and path, not only another location.

Internal success with external failure can help isolate a public routing, edge, or regional problem. It does not identify the cause without investigation.