> ## Documentation Index
> Fetch the complete documentation index at: https://docs.roark.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Load testing

> Run many simulations in parallel to surface latency, dropped calls and concurrency limits

## Why this is a common failure point

An agent that answers in 800 milliseconds on one call can take four seconds when fifty callers arrive at once. Model rate limits, tool backends, telephony capacity and your own infrastructure all degrade under load, and they degrade in ways a single test call never shows: slow first words, dead air mid-call, or calls that never connect. The first time most teams see it is during a marketing push or a Monday morning.

## How Roark tests it

Load testing runs one known-good flow many times in parallel, at the concurrency you set, and measures whether the agent stayed responsive and how its latency held up as volume rose. Because every call runs the same path, any change in behaviour is the load's doing.

***

## Setting it up

Load testing owns the run's scale, so the generic Iterations field in Advanced is hidden. Set the volume in the **Volume** panel:

| Field                | What it controls                                                                |
| :------------------- | :------------------------------------------------------------------------------ |
| **Concurrent calls** | How many calls run at the same time, capped by your account's concurrency quota |
| **Total iterations** | The total number of calls across the test                                       |

An estimated runtime updates as you change the numbers. Then pick **one flow to test**: the run uses its happy path on every call.

***

## What it measures

The template seeds these, and you can add or remove metrics in **Advanced** before running.

| Measure                      | What it tells you                                       |
| :--------------------------- | :------------------------------------------------------ |
| **Agent Responsive (check)** | Whether the agent stayed responsive for the whole call. |
| **Response Time**            | Time between speaking turns.                            |
| **Time to First Word**       | Time from the call connecting to the first spoken word. |

***

## What to look for

* **Latency against time, not the average.** Compare the first wave of calls with the last; a steady climb means something is queueing.
* **Unresponsive calls.** One call where the agent stopped answering matters more than a slower average.
* **Test above your expected peak.** Run at 1.5 to 2 times the concurrency you expect so you find the limit before your callers do.

***

## Over the API

Run it with `POST /v1/simulation/run` and `"template": "load-testing"`. `GET /v1/simulation/template` lists what each template accepts.