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:
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.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 withPOST /v1/simulation/run and "template": "load-testing". GET /v1/simulation/template lists what each template accepts.