Load testing
Load tests live alongside functional features but are authored separately — in the app's Load section — and run on a dedicated cloud load pool. A load test is a feature of kind load; it replays your generated feature journeys as concurrent browser users (simple mode) or drives protocol-level k6 traffic (advanced mode), depending on its configuration.
Full authoring is available from CI or an agent — create, edit, and delete load tests, then dispatch runs. REST accepts custom stages in the config. The CLI/MCP wrappers expose the simpler users + ramp + duration controls.
| Operation | What it does |
|---|---|
list_load_tests | List the project's load tests (id, name, status). |
create_load_test | Create a load test from a configuration. |
update_load_test | Rename a load test and/or merge configuration changes. |
delete_load_test | Delete a load test. |
run_load_test | Dispatch a load run onto the cloud load pool. |
A dispatched load run shares the run spine, so you read it back with the runs operations — get_run, wait_for_run, and REST list_runs with includeLoad=true surface load runs. Live latency / RPS / VU charts and server telemetry render in the app's Load section.
The dispatch → poll pattern is described in Long-running operations.
Read measurements using GET …/runs/{runId}/load-results (optional samples=true), MCP get_load_run_results, or testvibe load results <runId> --json. The result includes summary, thresholds, thresholdSummary, metrics, metricsBasis, sampleCount, and optional raw samples. These are load-generator measurements; list_server_metrics reports target-server telemetry.