Intermittent HTTP 500 from snow_adc on about 1 in 4 new connections (PDI, Australia release)

[test-qa01]

Our PDI (Australia release) answers HTTP 500 to about a quarter of new connections. The instance itself is healthy: the UI works and the same request passes on a retry.

What we measured

- The 500 is a static HTML page (173 bytes) with Server: snow_adc, Connection: close, no cookies, no X-Transaction-ID and no Server-Timing. It arrives about 0.13 s after the TLS handshake, so the request does not seem to reach the instance. A 200 from the same balancer carries X-Transaction-ID and Server-Timing.

- It happens only as the first response on a new connection. Requests sent over an already open connection passed 86 of 86.

- Each request below used a new connection to the same client and endpoint. POST /oauth_token.do, 5 s apart, gave 200 at 07:24:40Z, then 500 at 07:24:45Z and 07:24:50Z. GET /api/now/table/cmdb_ci_linux_server?sysparm_limit=1 gave 500 at 07:34:08Z and 07:34:11Z (14 Oct 2026). All requests went to 148.139.239.216.

- It does not depend on our load or on authentication: with our load stopped, one unauthenticated GET every 10 s gave 500 on 34 of 116 requests (29%). The token endpoint gave 500 on 27 of 92 requests.

- Another PDI of ours, on the Zurich release, showed none during a bulk read of 2,891 CIs.

Questions

1. Is this a known problem of ADCv2 on this release?

2. Can someone check whether one node behind the balancer is unhealthy?

3. Is there a supported way to report this for a PDI?

For now we retry with backoff, which clears it.

[Tobi3]

This happens for me with normal usage of the instance all the time. It's basically unusable currently, because you never know whether your changes will get saved or not.