- No idea why this is happening, predictive routing queue depth spikes during load tests.
- Using JMeter to simulate 100 concurrent calls to a specific routing strategy.
- Environment is US1, Architect version 2024.1.
- Calls enter the queue but agents never receive them.
- No error codes in the UI, just silent failure.
- WebSocket connections remain stable.
- Checking API logs shows no 429s.
- Does predictive routing have a hidden concurrency limit for new users?
Have you tried checking if your predictive routing strategy is hitting the maximum concurrent session limit for your specific edition? Coming from a Zendesk background, we were used to simpler queue logic where overflow was handled differently. In Genesys Cloud, predictive routing is aggressive, but it has hard limits on how many calls it can attempt to connect simultaneously before it stops sending invitations to agents. This often looks like a silent queue spike rather than an explicit error.
The issue usually stems from the “Maximum Concurrent Sessions” setting in the Routing Strategy. If JMeter pushes 100 calls at once, and your strategy is capped lower, the system holds them in the queue but cannot match them to agents because the predictive engine pauses to prevent overload. It’s not a bug, it’s a safeguard.
Try this configuration check:
- Navigate to Admin > Routing > Routing Strategies.
- Select the specific strategy used in your test.
- Look for the Predictive tab or section.
- Check the Maximum Concurrent Sessions value. If it’s set to a low number (like 50), increase it to match your test load or your license capacity.
- Also verify the Agent Selection criteria. Ensure you aren’t filtering out agents based on skills that JMeter isn’t simulating correctly.
In Zendesk, we didn’t have this level of granular control over predictive algorithms, so this step is new for many of us migrating. The key is aligning the JMeter script’s skill attributes with the Genesys Cloud skill requirements. If the skills don’t match, predictive routing won’t even attempt to ring, causing that weird queue buildup. Double-check your JMeter payloads include the correct skill headers. This usually resolves the “silent failure” immediately.
It depends, but generally…
- Adjust JMeter HTTP Request sampler timeouts to prevent SIP 408s before the platform processes offers.
- Check predictive routing concurrent session limits, as silent queue spikes often indicate hitting hard caps rather than API errors.