Does anyone know the exact default timeout value for HTTP requests within an Architect flow data action?
The performance dashboard indicates successful completion, yet the flow logs show a 504 error after exactly 30 seconds. Need to confirm if this is a hard platform limit or a configurable parameter.
To fix this easily, this is to recognize that the 30-second limit is a hard platform default for standard HTTP data actions. It is not configurable in the Architect UI. When running load tests with JMeter, if the external endpoint takes longer than 30 seconds to respond, the flow fails with a 504, even if the backend eventually processes the request.
For high-throughput scenarios, consider switching to an asynchronous pattern. Instead of waiting for the HTTP response in the flow, send the payload and move on. This prevents the flow from stalling during peak concurrent call volumes. The documentation confirms this behavior and suggests using webhooks for long-running processes.
See: Support Article KB-9921: Data Action Timeout Limits
This approach aligns better with API rate limits and keeps the WebSocket connection stable during ramp-up phases.
You might want to check at the carrier’s specific SIP timeout settings, as the 30-second platform limit is often exceeded by APAC carriers during peak hours. If your BYOC trunks are routing through regions with high latency, the upstream provider might be dropping the INVITE before the platform timeout even triggers, causing the 504.
The way I solve this is by bypassing the synchronous HTTP Data Action entirely when testing concurrent throughput. The 30-second hard limit is a bottleneck for load testing because it blocks the thread in the Architect flow, reducing overall API throughput.
Here is a JMeter setup to verify the actual latency of the external endpoint without hitting the flow limit:
<!-- JMeter HTTP Request Sampler -->
<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="External Endpoint Test">
<stringProp name="HTTPSampler.domain">api.external-service.com</stringProp>
<stringProp name="HTTPSampler.port">443</stringProp>
<stringProp name="HTTPSampler.path">/process-request</stringProp>
<stringProp name="HTTPSampler.method">POST</stringProp>
<boolProp name="HTTPSampler.follow_redirects">true</boolProp>
<boolProp name="HTTPSampler.use_keepalive">true</boolProp>
<stringProp name="HTTPSampler.connect_timeout">5000</stringProp>
<stringProp name="HTTPSampler.response_timeout">60000</stringProp> <!-- 60s timeout here -->
</HTTPSamplerProxy>
The key is to use an asynchronous pattern. Instead of waiting for the HTTP response in the Architect flow, send the request and immediately proceed. Use a webhook or a polling mechanism to check the status later. This prevents the 504 error from blocking the flow execution.
When scaling to 100+ concurrent calls in ap-southeast-1, the platform’s WebSocket connections can also become a constraint. If the external service takes 45 seconds, the Architect flow will fail, but the backend might still process it. This creates orphaned transactions that are hard to track.
By using JMeter with a longer response timeout (e.g., 60 seconds) and testing the endpoint directly, you can confirm if the 504 is due to the platform limit or the external service latency. If the external service is slow, consider optimizing the payload or using a message queue like RabbitMQ or Kafka to decouple the Architect flow from the external dependency. This approach maintains high throughput and avoids the hard platform timeout.
The root of the issue is that the 30-second synchronous block is a hard architectural constraint for data actions, not a configurable setting in the UI. this aligns with the asynchronous pattern suggested above. when integrating with serviceNow, relying on a synchronous HTTP call for ticket creation during high-volume digital channel bursts will inevitably trigger these 504s. the platform drops the thread to protect flow stability.
a more robust approach for serviceNow integration is to use an asynchronous webhook trigger. instead of waiting for the REST API response, the architect flow pushes the payload to a middleware endpoint (like azure functions or aws lambda) that queues the request. the middleware then handles the retry logic and eventual consistency with the serviceNow table api.
this removes the 30-second timeout from the critical path. you can still correlate the interaction by passing the conversation ID in the payload header. it adds a slight delay in ticket creation visibility but prevents flow failures. check the serviceNow inbound action docs for best practices on idempotency keys to avoid duplicate incidents if retries occur.