Need some help troubleshooting... Data Action timeout during high concurrency load test

Need some help troubleshooting… We are seeing a spike in 504 Gateway Timeout errors when executing a custom Data Action via the Architect API during our latest JMeter load test. The setup involves a simple GET request to an internal microservice that returns a JSON payload with customer preferences. Under low concurrency (50 simultaneous users), the response time is stable at roughly 120ms. However, as we ramp up to 150 concurrent sessions, the Data Action node fails consistently after 3 seconds.

The environment is Genesys Cloud US East, and we are using JMeter 5.6.2 for the load generation. The Data Action is configured with a standard timeout of 3000ms. We have verified that the target microservice can handle the load independently; the errors seem to originate from the Genesys Cloud integration layer. The error log in Architect shows:

Error: Request timeout. The server did not respond within the allowed time.

We checked the API rate limits for the tenant and confirmed we are well within the threshold for POST /api/v2/architect/data-actions. The issue appears to be related to the WebSocket connection handling or the internal queueing of the Data Action execution. We tried increasing the timeout to 5000ms, but this only delayed the failure; it did not resolve it. The failures are not random; they happen in batches when the concurrent session count exceeds 100.

Is there a known limit on the number of concurrent Data Action executions per Architect flow? Or is this a limitation of the WebSocket connection pool in the current version of Genesys Cloud? We are looking for guidance on how to optimize the Data Action configuration or if there is a specific header we need to include in the JMeter request to handle the concurrency better. Any insights on the internal throttling mechanism for Data Actions would be appreciated. We want to ensure our load testing accurately reflects production capacity without hitting artificial ceilings in the test environment.

What’s happening here is that the Data Action node is likely hitting the platform’s request throttling limits rather than a genuine backend failure. When concurrency spikes to 150 sessions, the Architect flow attempts to execute parallel outbound calls that exceed the default rate limit for custom integrations.

504 Gateway Timeout: Request exceeded maximum wait time of 30000ms

This error usually masks a server-side queue rejection. Instead of relying on simple retry logic, implement exponential backoff within your JMeter test plan to respect the Retry-After header. Additionally, check if your Data Action configuration has “Failover” enabled. If not, add a fallback node to prevent the entire flow from stalling.

For WFM scheduling, we often see similar bottlenecks when publishing bulk updates during peak hours. The fix is rarely about the code itself, but about how the platform handles concurrent write operations. Adjust your JMeter thread group to use a Concurrency Thread Group with a controlled ramp-up, and ensure your microservice returns a 202 Accepted status for asynchronous processing if possible. This shifts the load away from the synchronous Architect execution path.