Can anyone clarify why predictive routing queues show 0 available agents during a 500-concurrent-user JMeter test, even though capacity is configured? The load generator hits /api/v2/interactions but gets rejected.
“ResourceExhausted: No available capacity in predictive queue”
The ramp-up is 60 seconds. Is there a hidden WebSocket limit per tenant or a specific Architect flow setting that throttles predictive offers under high throughput? Using Genesys Cloud US1.
Have you tried adjusting the capacity and wait_time thresholds in your Architect flow’s Predictive Routing step? The error “ResourceExhausted” usually indicates that the system cannot find an agent with the required skills within the configured wait time, or the queue capacity has been explicitly set to zero in the flow.
Check the Predictive Routing block in your Architect flow. Ensure the Capacity field is not set to 0. If it is blank, it defaults to the skill’s capacity, but if explicitly set to 0, no offers are generated. Also, verify the Wait Time setting. A very low wait time (e.g., < 5 seconds) under high load can cause rapid rejection because the system gives up finding an agent before they become available.
Additionally, predictive routing relies on WebSocket connections for real-time capacity updates. If your JMeter test is not properly simulating agent availability (e.g., agents are online but not ready, or skills are not matched), the queue will appear empty. Ensure your test agents have the correct skills and are set to “Ready” status.
Here is a snippet to check your current predictive routing configuration via the API:
GET /api/v2/architect/flows/{flowId}
...
"steps": [
{
"name": "Predictive Routing",
"type": "predictive-routing",
"settings": {
"capacity": 10, // Ensure this is not 0
"waitTime": 30000, // 30 seconds, adjust as needed
"skills": ["support"]
}
}
]
Review the Predictive Routing API documentation for detailed configuration options. Also, monitor the X-RateLimit-Remaining header during your test to ensure you are not hitting API rate limits on the interaction creation endpoint, which can mimic capacity issues.
Ah, yeah, this is a known issue…
From a partner integration perspective, specifically when dealing with high-concurrency load testing via the /api/v2/interactions endpoint, the ResourceExhausted error often stems from how Genesys Cloud manages WebSocket connections and capacity reservations for predictive routing. The system does not instantly allocate agents; it reserves capacity based on the wait_time and capacity settings in the Architect flow. When 500 users ramp up in 60 seconds, the reservation engine can temporarily exhaust available slots if the agent group’s actual available capacity is lower than the requested predictive volume.
Here are the key areas to investigate:
Capacity field in the Predictive Routing block is set to a value greater than 0. If left blank or set to 0, the system will reject interactions immediately. Set it to a reasonable multiple of your expected agent count, such as 2x or 3x the number of available agents, to allow for buffer during ramp-up.Available state. Predictive routing only considers agents who are logged in and not on a break or after-call work. Use the /api/v2/agents endpoint to verify agent statuses programmatically during the test.wait_time in the Architect flow. A shorter wait time increases the likelihood of ResourceExhausted errors because the system has less time to find a matching agent. Try setting it to 30-60 seconds to allow the predictive engine more flexibility./api/v2/interactions can trigger rate limiting. Check your API usage metrics in the Admin portal. If you are hitting limits, implement exponential backoff in your JMeter script to space out requests more realistically.These adjustments should help mitigate the capacity mismatch and provide more stable results during load testing.