@kapa.ai, i have airbyte running on GKE cluster. When testing source connection through UI getting 502 error on the first try, but succeeds in the following tries. Have ingress timeout set to high value. Is there any other avenues could be looked at to resolve this issue?

The knowledge sources don’t describe a definitive root cause for “first attempt 502, subsequent attempts OK” on GKE, but they do point to a few concrete areas to check. From similar Kubernetes/GKE cases, 5xx/timeout issues during “Test connection” have most often been caused by: 1. Ingress / LB behavior (most likely in your case) - Several users saw 502/504 only when going through Ingress, while the same operation worked when using

kubectl port-forward

directly to the Airbyte service. [[K8s check conn](https://discuss.airbyte.io/t/594); [502 timeout](https://discuss.airbyte.io/t/1207)] - In those cases, the backend (Airbyte server + worker pods) actually completed the check, but the Ingress/LB timed out or dropped the first long‑running request. - You already increased timeouts, but double‑check that: - The Ingress is pointing to the correct service (for recent versions, typically the

airbyte-server

service, not just the webapp). [[Ingress doc](https://docs.airbyte.com/platform/deploying-airbyte/integrations/ingress)] - All relevant timeout annotations are set on the server ingress, not only the UI/webapp ingress (e.g. NGINX

proxy-read-timeout

,

proxy-send-timeout

, etc.). Too‑short backend timeouts are explicitly called out as a cause of 504/5xx during source/destination creation. [[Ingress doc](https://docs.airbyte.com/platform/deploying-airbyte/integrations/ingress); [1.8 ingress](https://docs.airbyte.com/platform/1.8/deploying-airbyte/integrations/ingress)] 2. Ingress controller / cloud LB specifics - For cloud LBs (GKE Ingress, AWS ALB, etc.), the docs recommend relying on the controller’s own annotations and ensuring it’s correctly installed and healthy. [[Ingress doc](https://docs.airbyte.com/platform/deploying-airbyte/integrations/ingress)] - In a similar GKE thread, removing the Ingress from the path eliminated the 504/502, confirming the issue was at the Ingress/LB layer rather than Airbyte itself. [[502 timeout](https://discuss.airbyte.io/t/1207); [K8s check conn](https://discuss.airbyte.io/t/594)] 3. Temporal / internal communication issues (less likely if retries always succeed) - Some users with persistent 502s during “Test connection” had problems with the Airbyte server talking to Temporal or worker pods. [[K8s check conn](https://discuss.airbyte.io/t/594); [502 timeout](https://discuss.airbyte.io/t/1207)] - In your case, since subsequent attempts succeed, this is less likely, but you can still: - Check

airbyte-server

,

airbyte-worker

, and Temporal logs around the first failing attempt. - Confirm all those pods are healthy and in the same namespace, and that there’s no restart or readiness issue on first use. 4. Verify behavior without Ingress - As in the referenced threads, test the same operation via:

bash      kubectl port-forward svc/airbyte-webapp-svc 8000:80

or directly to the server service, and run the connection test from

<http://localhost:8000>

. [[K8s check conn](https://discuss.airbyte.io/t/594); [502 timeout](https://discuss.airbyte.io/t/1207)] - If the first attempt works fine without Ingress, that strongly confirms the issue is with GKE Ingress / LB configuration rather than Airbyte itself. Because the sources don’t provide a GKE‑specific fix for “first attempt only” 502s, I can’t point to a single guaranteed solution. Based on what is documented, the most productive avenues are: - Re‑verify that your Ingress routes to the correct Airbyte service (server vs webapp) and that backend timeouts on that Ingress are sufficiently high. [[Ingress doc](https://docs.airbyte.com/platform/deploying-airbyte/integrations/ingress); [1.8 ingress](https://docs.airbyte.com/platform/1.8/deploying-airbyte/integrations/ingress)] - Temporarily bypass Ingress with

kubectl port-forward

to confirm the problem is Ingress/LB‑related. [[K8s check conn](https://discuss.airbyte.io/t/594); [502 timeout](https://discuss.airbyte.io/t/1207)] - Inspect server/worker/Temporal logs around the first failing attempt to rule out internal errors. If you can share your Ingress manifest (with sensitive data redacted), I can help you compare it against the documented examples and common patterns.