Runners
Runners execute HTTP, ping, port, and custom monitor checks. A monitor can use shared, long-running runners or, when enabled for the organization, a fresh cloud VM created for each check. Heartbeat monitors do not use runners because the monitored system sends pings to Testable.
Runner Modes
Shared
Shared mode uses an existing pool of long-running runners. The pool can be Testable hosted or self hosted.
Testable Hosted
Testable-hosted regions are public shared runner pools. Use them to monitor public services from multiple geographic locations without operating infrastructure.
Self Hosted
Self-hosted regions let you run checks inside a VPC, private network, data center, or customer environment. Use them for internal APIs, databases, private apps, and firewall-restricted services.
Per Check
Per Check mode starts a new runner VM for each monitor check. Depending on deployment configuration, the monitor form supports AWS, Azure, and GCP. Per-check runners are plan gated, and non-custom checks that use them are not eligible for the unlimited basic-monitor-check billing category.
Runner List
In Shared mode, the Runners page has tabs for Testable Hosted and Self Hosted runners plus filtering by name or region. Region rows show active, free, busy, and queued runner counts, public IPs, running checks, and map location when coordinates are available.
Runner Details
Expand a region to see individual runner hosts. Details include host, public IP, running checks, vCPU usage, memory usage, version, OS, last ping, uptime, and installed browsers.
Adding Self-Hosted Runners
The Self Hosted tab includes an add runner action that opens the runner setup modal. Follow the generated instructions for your environment and keep the runner online so it can poll for checks.
Managing Per-Check Runner Sources
Switch the Runners page to Per Check to view on-demand runner sources by cloud provider. Organization admins can register an AWS, Azure, or GCP account as a source, inspect its details, change its configuration, or delete a non-public source. Public and organization-specific sources can both be available.
Using Runners in Monitors
Non-heartbeat monitors choose one or more entries in the Regions panel. Plans that include location selection can add and remove region rows; otherwise the organization default region is used. Each row can use Shared or Per Check mode when the per-check feature is available.
Per-Check Region Configuration
For a per-check row, choose AWS, Azure, or GCP, select a region and runner source, then configure any source-specific network settings exposed by the source:
- AWS - VPC, any or a specific subnet, key pair, and optional Elastic IP selection.
- Azure - Resource group, network, subnet, and optional public IP selection.
- GCP - Network, any or a specific zone, and subnet.
Operational Guidance
- Use multiple hosted regions for public availability and latency visibility.
- Use self-hosted runners for private endpoints instead of exposing services publicly.
- Use per-check runners when checks need clean, short-lived infrastructure or cloud-account-specific networking.
- Register organization-owned per-check sources before configuring monitors that depend on their VPCs, networks, or subnets.
- Keep runner versions current so browser and runtime support remains compatible with custom scenarios.
- Monitor runner capacity by watching active, free, busy, and queued counts.
- Install browser dependencies required by Playwright, Puppeteer, or Selenium scenarios.