Architect Script Node Timeout with High Concurrency JMeter Load

Has anyone figured out why the Script Node in Genesys Cloud Architect starts returning 504 Gateway Timeout errors when we push concurrent sessions above 200? We are running a load test using JMeter 5.6.2 to validate the stability of our inbound flow. The environment is a standard production org in the us-east-1 region. We have configured the test to simulate 500 virtual agents logging in via WebSocket and then immediately entering a wrap-up state that triggers a specific Architect script. The script performs a simple data lookup via a REST API call to an internal service and then updates a custom attribute on the interaction.

The issue appears only when the request rate exceeds 200 requests per second. Below that threshold, the latency is stable at around 150ms. Once we cross 200 rps, the Script Node fails intermittently with a 504 error. We have already increased the timeout setting on the Script Node to 30 seconds, which is the maximum allowed. The internal REST endpoint is returning 200 OK within 50ms, so the bottleneck is not on the backend service side. We suspect it might be related to the thread pool exhaustion within the Genesys Cloud execution engine or some hidden rate limit on the internal service bus.

We are using the default thread group configuration in JMeter with a ramp-up period of 60 seconds. The WebSocket connections remain stable, and no disconnections are observed during the test. The error logs in Genesys Cloud show a generic “Service Unavailable” message without further details. We have tried adding a Constant Throughput Timer to cap the requests at 150/sec, which resolves the issue, but we need to validate performance at higher volumes. Any insights on how to debug this further or if there are known limits on Script Node concurrency? How can we resolve the 504 Gateway Timeout errors in Architect Script Nodes during high-concurrency JMeter load tests exceeding 200 rps?

I normally fix this by offloading the heavy lifting from the Architect Script Node to a Data Action. The script execution context has a strict timeout, so moving the logic to a serverless function or a ServiceNow webhook via Data Action prevents the 504 error. This keeps the flow responsive while handling the backend processing asynchronously.