Contact center load testing measures whether telephony, routing, and voice agents hold their service levels when call volume climbs toward peak. It drives a controlled number of concurrent calls through the live path, records connection failures, latency, and task outcomes at every hop, and finds the volume at which answer quality starts to degrade.
Most published guidance on this topic stops at the shape of the process: plan, simulate, monitor, analyse, retest. That sequence is correct and almost useless on its own, because it never says how much traffic to generate, which numbers count as a failure, or why a test that reports a clean pass has often generated a fraction of the load you asked for. This guide covers those three questions, in that order.
What is contact center load testing?
Contact center load testing is the practice of applying a known, repeatable volume of concurrent traffic to a live contact center stack and measuring where it degrades. It differs from functional testing in what it asserts. Functional testing asks whether a call routed to the right queue. Load testing asks whether it still routes to the right queue when 400 other calls are in flight.
The stack under test is deeper than most test plans assume. A single inbound call touches the carrier trunk, the SIP signalling layer, the IVR or voice agent, speech recognition, a language model, speech synthesis, any tools the agent calls, the routing engine, and finally an agent desktop or a queue. Each of those has its own concurrency ceiling, and the ceilings are rarely documented in the same place. The lowest one decides your real capacity, and it is almost never the one you expected.
Contact center performance testing is often used as a synonym. It is more accurately the superset: load testing (traffic at expected peak), stress testing (traffic past the ceiling, to find the failure mode), soak testing (moderate traffic for hours, to find leaks), and spike testing (a step change in seconds, to find what does not scale in time).
One scoping note. This guide covers the voice and telephony path through a contact center. Chat and email load testing follow the same concurrency principles, and the load model below applies to them unchanged, but the carrier, signalling, and speech layers discussed here do not.
What breaks first when call volume climbs?
The failures worth planning for are not the ones that produce a dropped call. They are the ones that produce a call that completes and is wrong.
Provider rate limits fire before your servers strain. Speech and telephony vendors cap concurrency per account or per project, and they return an error rather than degrading gracefully. Deepgram's published limits allow up to 150 concurrent streaming requests on Pay as You Go and up to 225 on Growth in North America, with enterprise tiers starting at 300. The detail that catches teams out is scoping: those rate limits apply per project, not per account or API key, creating additional projects under the same account grants no additional concurrency, and secondary projects created on a self-serve account are limited to a single concurrent stream by design. A load test run from a freshly created test project therefore hits a ceiling of one, and the resulting failures look like an agent problem. Deepgram also states that spreading traffic across projects to bypass the limit violates its terms of service, so the obvious workaround is not available.
Tool calls degrade before the agent does. The agent's own inference may hold its latency while the CRM lookup behind it queues. The transcript still reads fluently. The booking silently fails.
Timing bugs appear only in parallel. Race conditions in session state, connection pool exhaustion, and lock contention are invisible at one call and reproducible at fifty. They are also load-dependent rather than volume-dependent, which is why a soak test at moderate traffic can miss them entirely.
Quality drifts before availability does. Under strain, response latency creeps up, the agent pauses longer, and speech recognition accuracy falls as processing queues. Every call connects. Every call gets worse.
How do you build a load model?
The most common mistake is testing a round number. Two thousand concurrent calls is a satisfying target and tells you almost nothing, because it is not your traffic shape.
Three inputs give you a defensible model.
Peak concurrency, not peak volume. Concurrency is arrival rate multiplied by average handle time. Six hundred calls per hour at a four minute average handle time is 600 / 60 x 4, or 40 concurrent calls, not 600. Pull both numbers from your own historical reporting, at the busiest interval you have on record, not the daily average.
Headroom above that peak. Test at your observed peak, then above it. If production peaks at 40 concurrent, the useful test points are 40, 60, and 100. What you need to know is how much room exists above real traffic before quality moves, not the absolute ceiling of the platform.
The mix, not just the count. A contact center peak is not one scenario repeated. It is a distribution: some callers reach the IVR and self-serve, some transfer to a human, some abandon, some call from noisy environments, some interrupt. Load applied through a single happy-path scenario will pass at volumes that a realistic mix fails, because the expensive paths are the rare ones.
Which metrics tell you the system is failing?
Telephony has had standard, precisely defined failure metrics for over a decade, and contact center test plans almost never use them. RFC 6076, a 2011 IETF Standards Track document titled "Basic Telephony SIP End-to-End Performance Metrics", defines the vocabulary.
| Metric | What it captures | Why it matters under load |
|---|---|---|
| Session Request Delay (SRD) | Delay in responding to a session request | Rises before connections fail outright |
| Session Establishment Ratio (SER) | INVITEs answered with 200 OK, over INVITEs attempted less 3XX | The clean measure of "did the call connect" |
| Ineffective Session Attempts (ISA) | Setup requests released internally in a failed or overloaded condition | The direct overload signal |
| Session Completion Ratio (SCR) | Dialogs completing without failing for lack of response | Separates connection failure from mid-call failure |
| Session Disconnect Delay (SDD) | Time taken to end a session | Catches teardown backlogs that consume ports |
RFC 6076 is explicit that these capture overload, not just error. Ineffective session attempts are defined as occurring when a proxy or agent internally releases a setup request under a failed or overloaded condition, and the document lists 408 Request Timeout, 500 Server Internal Error, 503 Service Unavailable, and 504 Server Time-out as the failure responses that guide the count. It adds that 408 responses may indicate an overloaded downstream element, while noting that causes other than overload can also raise them.
Layer three application metrics on top of those signalling metrics: response latency at the p90 and p99 rather than the mean, task completion rate on the scenarios you actually care about, and a talk ratio or equivalent measure of whether the agent's speaking pattern has shifted. Means hide the failures. A 1.4 second average response with a 9 second p99 is a bad system that reports as a good one. The full set of voice agent evaluation metrics covers how each of these is defined and scored.
Why does a load test pass when it should fail?
This is the single highest-value thing to know before running a contact center load test, and none of the pages currently ranking for the term mention it.
Your load generator is rate limited, and it queues rather than rejects.
Twilio documents this behaviour plainly for outbound calls: by default each account is granted one call per second for calls created through POST requests to the /Calls endpoint, and accounts with an approved Business Profile can raise that to five. Crucially, calls beyond the account's CPS limit are queued and execute at the CPS rate rather than being refused.
Follow the arithmetic. You ask for 500 concurrent calls at one call per second. The first call starts at second zero. The five hundredth starts at second 500, more than eight minutes later. If your test scenario runs for 90 seconds, the first call ended six minutes before the last one began. Peak concurrency during that test was somewhere near 90, not 500. Every metric comes back clean, and you have tested roughly a fifth of the load you believe you tested.
The correction is a rule you can apply to any generator: the scenario must run for at least as long as it takes to dial the whole test. Divide target concurrency by the generator's calls-per-second rate, and make the minimum call length at least that number of seconds. At 5 CPS, a 50 call test needs calls of at least 10 seconds and a 100 call test needs at least 20 seconds. Any shorter and early calls finish before late ones start, so true peak concurrency is never reached.
Verify this rather than assuming it. Read the concurrency your platform reports at the midpoint of the run, not the count of calls you requested.
How the AI layer changes contact center load testing
A contact center running deterministic IVR menus fails predictably under load: ports exhaust, queues back up, callers wait. A contact center running voice agents adds failure modes that are probabilistic, and this is where older test plans lose their grip.
Speech recognition accuracy is load-sensitive in a way DTMF is not. A keypress is a keypress at any volume. A spoken postcode transcribed against a saturated streaming endpoint may lose digits. Language model responses lengthen or shorten under scheduling pressure, which shifts turn-taking and triggers barge-in behaviour that never appeared in single-call testing. Tool calls that succeed at low concurrency return late and get narrated as though they had returned data.
That means the assertions have to change too. Testing that the call connected is necessary and insufficient. The test needs to assert that the caller's task completed, on the same scenarios, at every load step, and compare the result against a baseline taken at a single call.
It is also worth knowing that platforms differ substantially in raw connection reliability before load enters the picture. Cekura's published benchmark of seven voice agent configurations found infrastructure-clean call rates ranging from 100% down to 72.36%, with one configuration recording 41 of 246 calls that did not connect at all. Cekura ran that benchmark as a frozen 82-scenario suite, three times per configuration, on single sessions rather than under concurrent load, so the figures describe the floor you start from rather than behaviour at peak. If a stack loses a quarter of its calls at benchmark volume, load testing is not the first problem to solve.
How do you run a load test without breaking the law?
A contact center load test generates automated calls with a synthetic voice. In the United States, that description maps directly onto regulated conduct.
47 CFR 64.1200(a)(1) prohibits initiating any telephone call, other than for emergency purposes or with the prior express consent of the called party, using an automatic telephone dialing system or an artificial or prerecorded voice, to any emergency line including 911, to the line of any guest or patient room of a hospital or health care facility, or to any number assigned to a cellular or other radio common carrier service.
The practical consequences are narrow and absolute. Load tests dial numbers you control, in a dedicated test range, or SIP endpoints in a staging environment. Never a production DID that real callers reach, never a list sampled from your CRM, and never a mobile number that happens to belong to a colleague who has not consented. Confirm the test range is excluded from any outbound campaign suppression logic before the first run, because a misrouted load test is a compliance incident rather than a failed test.
How Cekura runs contact center load testing
Cekura applies load through the same evaluators used for functional testing, scaled by a frequency parameter. Setting frequency to five on ten evaluators produces fifty concurrent calls against the agent, and each call is scored by the same criteria that scored it at frequency one. That design is deliberate: it means the load test measures task outcomes rather than connection counts, so a call that completes with the wrong answer registers as a failure.
Cekura applies three metrics by default to every load test run, documented in its load testing guide: Talk Ratio, which catches an agent stalling or repeating itself; Infrastructure Issues, which counts dropped calls, connection errors, and timeouts; and Latency, which measures the gap between the caller finishing a sentence and the agent replying. Cekura also lets you enable Expected Outcome alongside them to verify that core flows still complete under load.
Cekura schedules calls at five per second and documents the minimum call length that implies: target concurrency divided by five, in seconds. Cekura caps concurrency by plan, at ten concurrent calls on the Developer plan, and Cekura supports 2,000 or more concurrent calls on custom plans. Cekura advises that latency rising one to two seconds above baseline is a yellow flag while spikes past five seconds indicate infrastructure strain, and that any infrastructure issue at low frequency is a bug rather than a load problem.
For load testing a voice agent on its own, without the carrier CPS mechanics and dialing constraints specific to a contact center, the voice load testing guide covers that narrower case.
A ramp plan you can run this week
Run these steps in order and stop at the first one that moves a metric away from baseline.
- Baseline at one call. Record task completion, average and p90 latency, infrastructure issue count, which should be zero, and talk ratio. Every later number is read against these.
- Low load, two to three concurrent. Results should match baseline closely. A change here is a bug, not a capacity limit.
- Medium load, five to ten. Watch for the first latency creep. Note the number rather than acting on it.
- Your observed production peak. From the load model above. This is the number that decides whether you are safe today.
- High load, fifty to one hundred. Infrastructure issues typically appear somewhere in this band on an untuned stack.
- Stress, two hundred to five hundred. Run this to find the failure mode, not to pass. What you want is the shape of the break: does it queue, shed, or corrupt?
- Repeat each level two to three times. A single run is noisy. Consistent patterns across repeats are signal.
Two rules make the results interpretable. Change one variable at a time, so never adjust a prompt or a routing rule during a load campaign. And mock the downstream systems on at least one run, so that a failing CRM is distinguishable from a failing agent.
Frequently asked questions
What is contact center load testing?
It is the practice of driving a known volume of concurrent calls through a live contact center stack and measuring where performance degrades. It covers the carrier trunk, signalling, IVR or voice agent, speech processing, routing, and agent desktop. Unlike functional testing, which checks whether one call behaves correctly, load testing checks whether correct behaviour survives contention.
How many concurrent calls should we test?
Start from your own peak concurrency, which is arrival rate multiplied by average handle time, taken at your busiest recorded interval. Test at that number, then at roughly 1.5 and 2.5 times it. Round targets like 1,000 are useful only for finding the absolute ceiling, which is rarely the number that decides whether you are safe next Monday.
How often should contact center load testing run?
Before every launch or major release, before a known seasonal peak, and after any change to telephony routing, speech providers, or model versions. Provider concurrency limits and model behaviour change without notice, so a result more than a quarter old is a historical record rather than a current capacity statement.
Why did our load test pass when production still failed?
Most often because the test never generated the load it reported. Call generators are rate limited and queue excess calls rather than rejecting them, so short scenarios finish before the full set has dialled. Check the concurrency actually observed mid-run. The second common cause is testing one happy path when production traffic is a mix.
Does load testing catch voice AI quality problems?
Only if the test asserts task outcomes rather than call completion. Under load, speech recognition can drop digits and agents can respond late or narrate tool calls that have not returned, all on calls that connect and complete normally. Scoring each call against the same success criteria used at a single call is what surfaces these.
Can we load test against real phone numbers?
No. Automated calls placed with a synthetic voice fall under 47 CFR 64.1200(a)(1), which bars them to cellular numbers, emergency lines, and hospital rooms without prior express consent. Test against numbers you control in a dedicated range, or against SIP endpoints in staging, and confirm the range is excluded from outbound suppression logic first.
Ready to find where your contact center degrades? Talk to the Cekura team about running a load test against the scenarios you already use for functional testing.
