BYOC Edge status stuck on Degraded after Helm install

Problem

I am working to get the BYOC EDGE up and running on our internal cluster so we can ensure our WEM adherence data syncs complete successfully before the evening shift begins. I deployed this at 11 AM CST. The HELM install completes cleanly without any interruptions, but the EDGE status in the admin console remains stuck on “Degraded”. The POD is actively running, yet the connection to the CONTROL PLANE is not holding steady. I want to make sure our WEM routing and service level tracking remain uninterrupted, so I am looking into this connectivity gap thoroughly.

Code

Using HELM chart version 1.2.4. The VALUES file is configured with standard settings for the VPC environment.

edge:
 id: "byoc-edge-wem-01"
 region: "us-east-1"
 credentials:
 clientId: "..."
 clientSecret: "..."

Error

The POD logs are showing a timeout during the handshake process.

2023-10-24T16:32:11Z INFO Starting edge agent...
2023-10-24T16:32:15Z ERROR Connection refused: dial tcp 10.0.4.5:443: connect: connection timed out
2023-10-24T16:32:20Z WARN Retrying connection to control plane...

The FIREWALL is open on port 443. DNS resolves correctly from inside the POD. Running a manual curl to the endpoint works perfectly. However, the agent does absolutely nothing after the timeout occurs. It refuses to establish a connection. It is quite strange that curl succeeds while the agent fails. It just keeps looping through the retry logic, making the logs very noisy. I have verified the standard routing settings and confirmed there are no network policies blocking the traffic, but the agent still will not connect.

Question

The documentation mentions MTLS, but it does not specify whether the EDGE requires the internal CA BUNDLE to be injected. Is there a specific CERTIFICATE MOUNT required when the cluster is positioned behind a PROXY? I want to ensure our WEM adherence tracking and scheduling workflows are not impacted by this handshake failure. Any detailed guidance on the exact configuration steps or required mounts would be greatly appreciated.

I keep seeing the UI stuck on Degraded even when the control plane seems fine, so I think the web client cache is just holding onto old state. I tried hitting the status endpoint directly with a bearer token to verify the actual edge health, and if the API returns healthy it’s definitely just a frontend render issue. You can check the connectionStatus field in the response, and if it shows connected a hard refresh usually clears the cached state since the portal websocket reconnect logic sometimes hangs when the messenger widget loads before the edge initializes. Make sure to swap the edgeId placeholder with the actual UUID from your cluster deployment to avoid a 404, double-check that your token has the read:edge scope to prevent a 403, and watch for CORS errors in the headers even though direct curl usually bypasses them. If the lastHeartbeat timestamp is stale the pod is definitely struggling, so here’s the exact request I’m using, and does anyone know if there’s a simpler way to handle the widget initialization timing?

curl -X GET "https://api.mypurecloud.com/api/v2/edges/{edgeId}/status" \
-H "Authorization: Bearer {{access_token}}" \
-H "Content-Type: application/json"