Jitendra Singh Bisht
02/19/2026, 9:34 AMAirbyte is temporarily unavailable. please try again (HTTP 502)kapa.ai
02/19/2026, 9:34 AMabctl), and it’s not specific to your custom connector. Multiple users see the same “Airbyte is temporarily unavailable. Please try again. (HTTP 502)” when configuring any source or destination. [[Problem 502](https://github.com/airbytehq/airbyte/issues/66692); [Postgres 502](https://github.com/airbytehq/airbyte/issues/65567)] From the linked issues, the root cause is usually that the worker and workload API server are not correctly authenticated with each other (bearer token mismatch / missing), or their deployments need to be restarted. The workaround that consistently fixes it is: 1. Exec into the abctl container (if you’re running via abctl / Docker): bash docker ps # find the Airbyte container ID docker exec -it <containerID> bash 2. Inside the container, check pods: bash kubectl -n airbyte-abctl get pods 3. Generate a shared bearer token and set it on both services: bash BEARER_TOKEN=$(openssl rand -hex 16) echo "Generated token: $BEARER_TOKEN" kubectl -n airbyte-abctl set env deployment/airbyte-abctl-worker \ WORKLOAD_API_BEARER_TOKEN="$BEARER_TOKEN" \ INTERNAL_API_AUTH_TOKEN="$BEARER_TOKEN" kubectl -n airbyte-abctl set env deployment/airbyte-abctl-workload-api-server \ WORKLOAD_API_BEARER_TOKEN="$BEARER_TOKEN" 4. Restart both deployments and wait for rollout: bash kubectl -n airbyte-abctl rollout restart deployment airbyte-abctl-worker kubectl -n airbyte-abctl rollout restart deployment airbyte-abctl-workload-api-server kubectl -n airbyte-abctl rollout status deployment airbyte-abctl-worker kubectl -n airbyte-abctl rollout status deployment airbyte-abctl-workload-api-server Users report that after doing this, creating sources (including file, Postgres, MySQL, etc.) works again and the 502 disappears. [[Problem 502](https://github.com/airbytehq/airbyte/issues/66692)] If you’re not using abctl or this doesn’t match your deployment, the knowledge sources don’t provide more specific steps for other setups; in that case, the best next move is to check your platform logs (worker / workload API / temporal) for 401/502 errors and compare with the issues above.