BYOC Edge Webhook Payload Timeout for ServiceNow Incident Creation

Voice & Telephony
1

Can’t quite understand why the outbound webhook from our BYOC Edge node is consistently timing out when triggering ServiceNow incident creation via Data Actions. The Edge is deployed in the London region, and the ServiceNow instance is on the AWS eu-west-1 cloud.

The Architect flow captures the digital channel event, processes it through a script node to format the JSON payload, and then calls the ServiceNow REST API. The issue arises specifically when the payload exceeds 2KB. Smaller test payloads succeed immediately. The Edge logs show a 408 Request Timeout returned by the ServiceNow integration endpoint, yet checking the ServiceNow system logs reveals the request was never received.

This suggests the packet is dropping at the Edge node’s outbound proxy or the TLS handshake is failing silently under load. We have verified the certificate chain is valid and the proxy settings in the Edge configuration file are correct. The timeout parameter in the HTTP node is set to 30 seconds, which should be sufficient.

Is there a known limitation with the BYOC Edge connector regarding large payload handling or specific TLS 1.3 cipher suite compatibility with ServiceNow’s API gateway? How can we increase the buffer size or adjust the keep-alive settings on the Edge node to prevent these intermittent drops?

2

This looks like a standard edge-to-cloud latency issue rather than a payload size constraint.

  1. Enable the async execution flag in the Data Action configuration.
  2. Add a retry policy with exponential backoff to handle transient network blips between London and AWS.
3

The simplest way to resolve this is to offload the ServiceNow call to a background task via WFM API triggers, since blocking the media path for external HTTP calls is a recipe for timeouts regardless of payload size. Just ensure the schedule adherence rules account for the async processing delay.

4

This looks like a configuration oversight in the Data Action node rather than a network issue.

"timeout": 10000,
"retry_on_failure": true

Increase the timeout threshold to accommodate the larger payload transmission time.