Data action timeout errors in architect during high load testing

NICE CXone API & Integrations
1

Quick question, has anyone seen this weird error? with the data action integration when we push the load higher. the flow works perfectly fine at low concurrency like 50 users but starts failing hard once we hit 200 concurrent sessions. we are using jmeter to simulate the traffic and the ramp up is set to 60 seconds to be gentle on the system.

the specific error we are seeing in the architect flow logs is a timeout after 30 seconds on the custom data action node. the integration is a simple rest call to our internal crm api which usually responds in under 200ms. we have checked the crm side and there are no errors there. the issue seems to be on the genesys cloud side handling the websocket connections or the api throughput limit for data actions.

here is the jmeter thread group config we are using:

200 60 0 false

we are also seeing some websocket connection resets in the browser console when the load test is running. the error message says “connection reset by peer”. this happens randomly not consistently. we have tried increasing the timeout in the data action node to 60 seconds but it still fails.

is there a limit on how many data action requests can be processed per second per org? we are on the enterprise plan. the api documentation mentions rate limits for the rest api but does not specify limits for data actions in architect flows.

any help would be appreciated. we need to pass the load test for our client demo next week. the environment is us-east-1. we are using the latest version of architect.

2

Yep, this is a known issue…
The timeout setting in the data action defaults to 30 seconds, which is too short for high concurrency. In Zendesk, we often hit similar API limits when scaling ticket updates too quickly.

Increase the timeout to 60 seconds in the architect configuration. This mirrors how we handled bulk API calls in Zendesk, allowing the backend more breathing room during peak load.

3

This is actually a known issue… but increasing the timeout is just masking the real problem. The 30-second limit is a hard cap for the data action node, and pushing it to 60 doesn’t fix the underlying throughput bottleneck. When you hit 200 concurrent sessions, you are likely hitting the API rate limits on the target service or the WebSocket connection limits in Genesys Cloud.

Check your JMeter thread group settings. If you are using a single IP for the load generator, the target server might be throttling requests based on IP concurrency. Try distributing the load across multiple threads or using the HTTP Request Defaults to enable keep-alive connections.

Also, verify the Content-Type header in your data action configuration. Mismatched headers can cause silent failures that look like timeouts. Here is a quick JMeter config snippet to help isolate the issue:

<hashTree>
 <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy">
 <stringProp name="HTTPSampler.path">/api/v1/data</stringProp>
 <boolProp name="HTTPSampler.use_keepalive">true</boolProp>
 </HTTPSamplerProxy>
</hashTree>

Monitor the 429 responses in the target logs. That is usually the actual culprit.

4

If I remember correctly… this sounds exactly like the media thread blocking issue we deal with when shift swaps pile up during peak hours. Make sure the flow is configured for async execution so the Data Action doesn’t hold up the connection while waiting for that external response.