Runner locations
Location classes, what each can and cannot tell you, the runner identity on every Observation, location keys and how region comparison works.
v1Updated
Geography, cloud region and access network answer different questions, so ScoutSentinel offers several location classes. Each Watch has a location policy and every Observation records exactly which runner produced it.
Location classes
| Class | What it is | Best for | What it cannot tell you |
|---|---|---|---|
edge |
Cloudflare Workers and Browser Rendering, selected by geographic policy | Broad, low-cost routine probes from many cities | The network is Cloudflare, not a consumer ISP; egress addresses are not stable |
regional |
Small hardened containers with a pinned browser image in a named cloud and region (AWS, GCP or Azure) | Deterministic cloud-region comparison, stable egress addresses for allowlisting | Residential or mobile realism |
private |
Outbound-only runner you operate in an office, VPC, branch or contact centre | Internal or private-service reachability from your own network | Anything outside the network it sits in |
partner |
Telephony and network partners with contractually defined origins | Carrier, mobile and residential realism | Coverage we would rather not fake with cloud runners |
Which classes your organisation may select is an entitlement of your plan; GET /v1/locations lists every location with its class, provider, region, capabilities, whether it is entitled for you and whether it is online.
Runner identity
Every Observation carries a runner object:
| Field | Values | Meaning |
|---|---|---|
runnerId |
string | The registered runner instance |
provider |
cloudflare, aws, gcp, azure, local, customer, partner |
Who operates the runner |
region |
string, for example lhr, eu-west-2, australia-southeast1 |
Provider region label |
networkClass |
edge, cloud, private, carrier, local |
The access network the request left from |
runnerVersion |
string | Runner software version |
browserVersion |
string, optional | Pinned Chromium build for browser probes |
probeVersion |
string | Version of the step DSL and executors (currently 0.1.0) |
The three identity fields that define a vantage point form the location key provider:networkClass:region, for example cloudflare:edge:lhr or aws:cloud:eu-west-2. It appears as locationKey on Observations, as a filter on runs and events, in the region picker, and as locations[] on an Event. The human label drops the colons: cloudflare edge lhr. Corroboration in the materiality policy counts distinct location keys, so two runners in the same provider, network and region are one location.
Comparisons across locations are only made when probe version, browser image, assertion set and time window match; the Locations tab marks each location comparable or not, and evidence comparison lists the reasons a pair is not like-for-like.
Location policy on a Watch
{ "classes": ["edge", "regional"], "regions": ["lhr", "fra", "syd"], "minLocations": 2 }classes selects one or more location classes, regions optionally narrows to named regions, and minLocations (default 1) is how many distinct locations should observe every schedule slot; it feeds coverageLocations assertions and the confidence shown on an Event. A probe inside the Watch may carry its own locationPolicy to run, for example, a DNS check from one place while the browser journey runs from three. materiality.corroboratingLocations decides how many of those locations must agree before an outcome Event opens.
Regional runners
Regional runners register with a one-time bootstrap token, sign every request to the platform with an Ed25519 key that never leaves the runner, receive short-lived jobs by long-polling and upload evidence through the API where its hash is verified before the metadata row is written. Secrets a job needs are decrypted for that job only and never persisted by the runner.
Open a journey’s Locations tab to review recorded locations and requested location policies. This view does not publish static egress addresses or confirm that every requested runner is available. Obtain the actual egress addresses from the operator of your deployed runner before allowlisting; do not infer them from a region label. See also the synthetic traffic markers.
Private runners
Private runners are the same software run on your infrastructure with provider: customer and networkClass: private. They make outbound, mutually authenticated connections only and never require an inbound management port. The app shows health, version, last contact and the network identity each runner reports. A runner that is shut down or loses contact reports its in-flight jobs as unknown with reason runner_disconnected, never as a target failure.
Separating runner failure from target failure
Every runner runs a canary journey against a page it serves itself before it leases any work, and repeats it every ten minutes. A runner whose canary fails stops leasing, and any job it could not execute for its own reasons is recorded as unknown with reason runner_error. Three consecutive unknowns for a Watch open a low-severity coverage Event so the gap is visible; your journey is never marked failed by our infrastructure problem.