Your functional tests prove a journey works once. They say nothing about what happens when a few dozen people run that journey at the same time. TestVibe closes that gap with built-in load testing: the same journeys you already generated as Playwright tests can be replayed by concurrent browser users, or you can point protocol-level k6 traffic at your endpoints — no scripts to write, no separate tooling to operate.
This is a practical walkthrough: what TestVibe load tests are, how to configure one, how to run it, and how to read the results.
What a TestVibe load test is
Load Testing lives in its own section of the navigation rail, separate from functional Runs. Under the hood, load tests share the same run infrastructure as your functional tests — the same dispatch, the same cloud fleet, the same live-updating results — but the workload is different. A load test runs in one of two modes:
- Simple — concurrent browser users replay your generated feature tests and time every step. No k6 script involved. This is the easiest path and the most realistic: real browsers, real UI-level load, per-step latency.
- Advanced — protocol-level k6 load with a configurable profile (paths, virtual users, ramp, duration, think time) and pass/fail threshold gates. TestVibe generates the k6 script for you, and you can review it before anything runs.
The relationship to functional runs is simple: a journey needs a generated test before it can be used in a Simple load test. If you haven't generated tests yet, Advanced mode still lets you drive URL-based load at your endpoints.
Configuring a load test
Everything happens on the load test's Configure tab. You can switch a saved test between modes at any time.
- Select Load Testing in the navigation rail.
- Select + (New load test) in the list rail.
- Pick Simple or Advanced with the toggle at the top of the form.
- Configure the mode's settings (below).
- Select Save, then Run when you're ready.
Simple mode settings
| Setting | What it controls |
|---|---|
| Features | The generated feature tests the browser users replay. Pick whole groups or individual features. |
| Users | How many browser users run concurrently, up to 100. Above 20 users, TestVibe automatically spreads the load across multiple cloud machines — you still see one test and one merged result. |
| Repeats per user | How many times each user replays the features. Users × repeats = total feature runs, and the form shows that math as you type. |
| Target | Which environment the users run against — pick one of the project's configured environments (the default is pre-selected) or type a Custom URL. |
Each user replays the selected features, then stops — the run ends when everyone finishes. Simple runs report per-step latency under load, so you can see which step of the journey degrades first.
Advanced mode settings
| Setting | What it controls |
|---|---|
| Target & paths | The URL the virtual users hit and the paths requested each iteration. |
| Load profile | Virtual users, total duration, ramp-up window, and think time. Users ramp from 0 to the target over the ramp-up, then hold. |
| Thresholds | k6 pass/fail gates such as p(95)<1000 on http_req_duration or rate<0.01 on http_req_failed. The run fails if any gate fails. |
| Generated k6 script | A read-only preview of the script TestVibe generated from this configuration — see exactly what will run before you start it. |
Threshold gates apply to Advanced runs only; Simple runs report timings without gating.
Sizing guidance
Start small — 10 users for 60 seconds is enough to validate the configuration end to end. Increase users gradually, and keep ramp-up at 10–20% of the total duration so the system warms up realistically. In Advanced mode, set thresholds from a passing baseline run rather than guessing, then tighten them once results are stable.
Running it
Select Run. The test dispatches to the cloud load fleet, the run appears on the Results tab immediately, and its charts update live while virtual users execute. Cancel stops an in-flight run; Delete removes a terminal one.
You don't have to click the button yourself, either. Load tests can be listed and dispatched from CI over the REST API, from the testvibe CLI (testvibe load run "Checkout under load" --wait makes a handy CI gate), or from AI tools via the MCP server. For a recurring schedule, create an Automation with a Run a load test action — no external scheduler needed.
Reading the results
The Results tab shows a strip of past runs — select one to inspect it. Each result opens with a What this run did block: the mode, target URL, load profile, and the features exercised, so a result is never ambiguous about what produced it.
From there, read top to bottom:
- KPI tiles give the headline: total requests with peak rate, latency p95, error rate, peak concurrent users, and — for Advanced runs — the threshold gates.
- Latency percentiles chart p50/p90/p95/p99 over time. This is the chart to watch: a rising p95 under steady load is your earliest saturation signal, long before averages move.
- Throughput, users, and error rate charts confirm the load actually ramped as configured, and let you correlate error spikes with load level.
- By step — latency under load (Simple runs) breaks out per-step p50/p95/p99 and error rate, so you can see which step of the journey degrades first — usually the one hiding the slow query.
Pass/fail semantics differ by mode. An Advanced run passes when every threshold gate holds for the whole run — a failed gate marks the run failed even if all requests technically succeeded. A Simple run has no gates; it fails when the replayed features fail under load.
Two quick sanity checks when a result looks wrong: a 100% error rate usually means the target URL was unreachable from the fleet — check the Target section and any access controls. Flat-zero throughput with running virtual users means journeys are failing before their first request; re-run the journey as a functional test first.
When you're done reading, Ask AI seeds the Assistant with a data-rich summary of the selected run — useful for sharing a quick verdict — and Export downloads the full results as JSON, the per-step/per-endpoint table as CSV, or the raw metric samples as CSV.
Going deeper: server telemetry
Client-side numbers tell you what users experience; server telemetry tells you why. Install the TestVibe telemetry agent in the app you're testing (a NuGet package for .NET, a single-file agent for Node.js) and your results gain live server-side CPU, memory, session, and custom metrics next to the client-side charts. CPU climbing toward saturation while p95 rises is the classic capacity ceiling; memory growing run-over-run without recovering suggests a leak the load test is exposing.
Wrap-up
Load testing in TestVibe is deliberately boring to operate: pick the journeys you already have (or the endpoints you care about), set users and duration, press Run, and read the charts. The heavy lifting — script generation, fleet dispatch, sharding across machines, merging results — is handled for you.
Want to try it on your own app? TestVibe is in early access — get early access and your first load test can be 10 users for 60 seconds. The load-testing docs cover every setting in detail.