Use a shared service to coordinate probes you run

Probing as a service means that Urth provides a shared control plane for probe definitions, job placement, and results. Execution takes place on customer-managed Workers. This model lets teams share a record of service behavior while keeping probe execution in the networks they control.

Define, execute, and inspect

A Scenario is a versioned definition of what to test and where it may run. Its prob field holds the probe configuration or script. Urth supports HTTP, TCP, DNS, ICMP, gRPC, REST request files, HAR replay, and browser scenarios. Support on a particular Worker depends on its build, runtime, and permissions.

A manual trigger creates a Result and places the job on an eligible Runner. An authenticated Worker collects and claims the job. It executes the probe and reports status, timing, and available Artifacts, such as logs, metrics, screenshots, or HAR files. Artifact types depend on the probe.

The web interface and urthctl use the same resource API. A local urthctl run -f scenario.yaml is useful for authoring, but it does not submit a job or upload a Result to the service. Use urthctl trigger for a recorded run. See Create test scenarios for authoring and Run scenarios locally for development and troubleshooting.

Understand the responsibilities

Responsibility	Who provides it
API, resource storage, job dispatch, and result access	The Urth control-plane operator.
Probe definitions and expected behavior	The customer project team.
Worker compute, deployment, restarts, updates, and capacity	The customer.
Runner registration, enrollment credentials, and project grants	Authorized customer administrators.
Target network access, DNS, TLS trust, and service credentials	The customer.
Script dependencies and browser runtimes	The customer, for the chosen Worker build.
Interpretation of results and operational response	The customer project team.

If you self-host Urth, you also operate the control plane, PostgreSQL, NATS, identity configuration, and storage. A working API does not prove that a Worker can reach the service being tested.

Keep probes safe and results meaningful

Start with read-only checks. Use test accounts and test data for workflows that change state. Execution is not guaranteed to occur exactly once. A Worker can fail after sending a request and before reporting the result. A probe that changes state needs its own protection against duplicate actions.

Treat scripts as code running with the Worker's access. Review them before execution. Limit the Worker's infrastructure permissions to what the probes need. HAR captures and browser artifacts can contain credentials or sensitive data. Review artifact contents and retention before using authenticated workflows. Secret injection from a secret store at replay time remains planned.

Continue with the quick start or the architecture guide.