Hi all,
We are observing intermittent 504 Gateway Timeout errors when executing a Data Action from a Genesys Cloud Architect flow hosted on our BYOC Edge Node (London region). The Data Action is configured to update a ServiceNow incident record via a standard REST API call. While the majority of requests succeed, approximately 15% of triggers fail with a timeout, specifically when the Edge Node attempts to establish the outbound HTTPS connection to the ServiceNow instance.
Our Edge Node is running version 2023.4, and the integration uses a dedicated OAuth client with read/write scopes for the target ServiceNow tables. The ServiceNow endpoint is publicly accessible, and direct testing from our on-premise network shows latency under 200ms. However, monitoring the Edge Node logs reveals that the timeout occurs during the initial TCP handshake or TLS negotiation phase, not during payload transmission.
I have verified that the Edge Node’s firewall rules allow outbound traffic on port 443 to the ServiceNow domain. Additionally, I have cross-referenced the Genesys Cloud documentation for BYOC networking constraints, but nothing indicates a limitation on outbound REST API calls from the Edge runtime. The issue persists regardless of the time of day, ruling out peak load scenarios on the ServiceNow side.
Has anyone encountered similar latency or timeout issues with outbound Data Actions originating from a BYOC Edge Node? Are there specific network configurations or proxy settings required on the Edge appliance to ensure stable connectivity to external SaaS providers like ServiceNow? Any insights into debugging the TLS handshake phase within the Edge environment would be appreciated.
The 504 Gateway Timeout in this context usually stems from the synchronous nature of the Data Action execution against the latency of the ServiceNow REST API, rather than a failure in the Genesys Cloud platform itself. Since you are hosting on a BYOC Edge Node in London, you need to consider the physical distance and potential routing inefficiencies between your edge infrastructure and the ServiceNow instance, especially if ServiceNow is hosted in a different region like US-East.
I recommend checking your outbound routing configuration for the Edge Node. Ensure that the Data Action is not attempting to route through a SIP trunk or an unexpected proxy that might be dropping long-lived HTTPS connections. For BYOC setups, it is critical to verify that the edge node has direct internet access for outbound HTTPS traffic and that no intermediate firewalls are imposing strict timeouts on idle connections.
You should also adjust the timeout settings within the Data Action configuration. The default timeout might be too aggressive for cross-continental API calls. Try increasing the timeout value to 30 seconds or more to accommodate the additional latency. Additionally, implement retry logic in your flow to handle transient network issues gracefully.
If the issue persists, capture packet traces on the Edge Node to identify where the connection drops. Look for TCP RST packets or incomplete handshakes. This will help determine if the issue is on the Genesys Cloud side, the network path, or the ServiceNow endpoint. Finally, ensure that your ServiceNow instance allows incoming connections from the IP ranges used by your BYOC Edge Node, as IP whitelisting can sometimes cause delays if the IP changes dynamically.