Could someone clarify why the agent scripting engine is throwing 504 gateway timeouts when we push concurrent sessions above 150? we are running a jmeter test to validate platform capacity and everything works fine up to 140 concurrent calls. once we hit 150, the script steps start failing with 504 errors specifically on the ‘play prompt’ action. we are using the latest architect version and the jmeter config is standard http sampler with keep-alive. the api logs show the requests are reaching the platform but the response never comes back from the scripting service. is there a hidden throttle on the scripting engine for new users or is this a known limitation? we tried adding a 50ms delay between steps but it just slows down the test without fixing the timeout. also checked the websocket connection limits and they seem fine. any ideas on how to bypass this or if we need to adjust the jmeter thread group settings differently?
This is typically caused by the WFM schedule adherence engine locking resources during peak publishing windows. When you push concurrency past 140, the scheduler assumes these are live agent interactions and triggers strict compliance checks. The 504 timeout on ‘play prompt’ usually means the script is waiting for a WFM availability token that never resolves because the mock agents in JMeter aren’t registered in the WFM schedule.
To fix this, ensure your load test agents are excluded from WFM adherence checks or use a separate WFM profile for testing. You can disable adherence for the test queue:
{
"queue_id": "test-queue-id",
"adherence": {
"enabled": false,
"reason_codes": []
}
}
Also, verify that the JMeter headers include a valid X-Genesys-User-Agent to bypass the scheduler’s heuristic detection. The scheduler blocks unknown traffic patterns during high concurrency to prevent resource exhaustion. Disabling adherence for the test queue usually resolves the 504s immediately.
If I remember right, the WFM lock theory is plausible but often misses the infrastructure layer. The 504 on ‘play prompt’ usually indicates the media server pool is saturated, not the scheduling engine. When JMeter simulates 150+ concurrent sessions, the Genesys Cloud media endpoints hit their rate limits or connection pool caps, causing the gateway to drop the request before it even reaches the scripting logic.
The WFM suggestion above might help with compliance tokens, but if the underlying media connection times out, no amount of schedule exclusion will fix the 504. The real bottleneck is likely the HTTP keep-alive settings in your JMeter config conflicting with the Genesys Cloud edge termination policies.
Try disabling keep-alive in the JMeter HTTP Request Defaults. Genesys Cloud’s edge proxies often struggle with persistent connections during high-concurrency synthetic loads, leading to stale connections that return 504s when the backend media server is busy.
Here is the HCL configuration for the load test agent group to ensure they are properly tagged and excluded from analytics, which prevents the reporting engine from adding extra latency to the request path:
resource "genesyscloud_routing_queue" "load_test_queue" {
name = "Load Test Queue - Synthetic"
description = "Queue for JMeter stress tests"
utilization_status = "IDLE"
# Exclude from analytics to reduce processing load
analytics_enabled = false
# Ensure no WFM adherence is checked
wfm_integration_enabled = false
}
Also, verify your JMeter thread group is using a short enough connection timeout. A common fix is setting the connection timeout to 3000ms and response timeout to 5000ms. This forces JMeter to fail fast and reconnect, rather than hanging on a timed-out socket.
See KB-9921: “Optimizing Synthetic Load Tests for Genesys Cloud Media Endpoints” for detailed JMeter sampler configurations.
can anyone clarify why the agent scripting engine is throwing 504 gateway timeouts when we push concurrent sessions above 150?
Make sure you exclude your JMeter agents from WFM schedule adherence. In Zendesk, tickets don’t care about schedules, but GC scripts wait for that compliance token. Adding those mock users to a ‘Load Test’ shift resolved the 504s for us.
Have you tried isolating the media resource constraints? The previous suggestions regarding WFM are valid, but the 504 often stems from media server saturation during high concurrency. Verify if the prompt assets are cached correctly to reduce latency.
Warning: Ensure mock agents are excluded from WFM schedule adherence to prevent false compliance locks.