Hi @kapa.ai. I keep getting "Airbyte is temporarily unavailable. Please try again. (HTTP 502)" and "Failed to save Postgres due to the following error: errors.http.badGateway" when creating a Postgres destination. I try to connect to a docker instance of Postgres 18. My Setup is the airbyte container containing kind. I've tried almost anything, Ifound in the internet. Still getting this. I have 8 cores and 32 GB memory. Docker is allowed to use all of that. So presumably this is NOT a resource issue.

Based on the knowledge sources, your HTTP 502 error when testing a connector (Postgres destination in your case) installed via

abctl

(the container with kind) is a known issue related to mismatched authentication tokens between internal Airbyte services — specifically, the

WORKLOAD_API_BEARER_TOKEN

is not aligned between the Worker and the Workload API Server pods. [HTTP 502 fix] Here is the workaround that has been confirmed to resolve this: 1. *Find your container ID:*docker ps 2. *Enter the container:*docker exec -it containerID bash 3. *Inside the container, run the following:*# Check current status kubectl -n airbyte-abctl get pods # Generate and apply matching auth tokens to both services 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" # Restart both services kubectl -n airbyte-abctl rollout restart deployment airbyte-abctl-worker kubectl -n airbyte-abctl rollout restart deployment airbyte-abctl-workload-api-server # Wait for rollouts to complete kubectl -n airbyte-abctl rollout status deployment airbyte-abctl-worker kubectl -n airbyte-abctl rollout status deployment airbyte-abctl-workload-api-server [HTTP 502 fix; 502 on connector setup] Alternatively, some users also needed to set the token on the server deployment as well:

kubectl -n airbyte-abctl set env deployment/airbyte-abctl-server \
  WORKLOAD_API_AUTH_HEADER=Authorization \
  WORKLOAD_API_BEARER_TOKEN=$TOKEN

[HTTP 502 fix] This is unrelated to your resource allocation (cores/memory), which confirms your suspicion. The root cause is an internal authentication mismatch between Airbyte's worker and workload API server components. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai, where or how do I check, if the pod spawn was triggered succesfully on saving the destination?

To check whether a pod was spawned when saving/testing a destination, you can watch the pods in your Kubernetes cluster in real time. Inside your abctl container, run:

kubectl get pods -n airbyte-abctl -w

or equivalently:

watch kubectl get pods -n airbyte-abctl

When you click "Test the Source/Destination", a check pod (e.g.

source-postgres-check-...

or similar) should appear and progress through statuses like

Pending → Init:0/1 → PodInitializing → Running → Completed

. [verify data plane] If no pod appears at all when you trigger the test, that is a strong indicator of the token mismatch issue described in the previous answer — the workload is never being claimed or scheduled. [HTTP 502 fix] You can also check for any scheduling errors with:

kubectl get events -n airbyte-abctl --sort-by=.lastTimestamp

This will show events like

FailedScheduling

or

FailedCreate

if the pod was attempted but failed to start. [pod creation failure] And to view logs from the workload launcher (which is responsible for spawning these pods):

kubectl logs -l app.kubernetes.io/name=workload-launcher -n airbyte-abctl --tail=100

[pod creation failure] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai, I tried everything described above. There is no sign of a spawned pod nor any "Failed" entries.

message has been deleted

@kapa.ai, I couldn't find any of the above mentioned entries.

That's a significant finding. If the worker logs show no

Unauthorized

error and the workload-launcher logs show no claim/skip messages at all when you trigger a test, it suggests the workload may not even be reaching the worker or launcher — meaning the issue could be earlier in the chain. Based on the knowledge sources, here are the remaining things to check: 1. Check the cron logs — the cron service monitors workloads and cancels ones that are "not started" or "not claimed":

kubectl logs -l app.kubernetes.io/name=cron -n airbyte-abctl --tail=200

Look for lines like:

Checking for not started workloads.
Checking for not claimed workloads.

If workloads are being created but immediately cancelled by cron, they would never reach the launcher. [Temporal context deadline] 2. Check the server logs — the server is responsible for initiating the check command:

kubectl logs -l app.kubernetes.io/name=server -n airbyte-abctl --tail=200

3. Verify all pods are actually healthy:

kubectl get pods -n airbyte-abctl

All pods (worker, workload-api-server, workload-launcher, server, cron, temporal) should show

Running

status with no excessive restarts. Beyond this, the knowledge sources do not contain enough information to diagnose further why no pod is spawned and no errors appear anywhere in the logs. This appears to be a deeper platform issue that would require escalation to the Airbyte team — I'd recommend opening a GitHub issue at airbytehq/airbyte with your logs and setup details (abctl version, Airbyte version, OS). 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai, 2026-04-10 165310,815 [scheduled-executor-thread-11] INFO i.a.c.j.WorkloadMonitor(cancelNotClaimedWorkloads):93 - Checking for not claimed workloads. 2026-04-10 165410,811 [scheduled-executor-thread-7] INFO i.a.c.j.WorkloadMonitor(cancelNotStartedWorkloads):66 - Checking for not started workloads. 2026-04-10 165410,811 [scheduled-executor-thread-15] INFO i.a.c.j.WorkloadMonitor(cancelRunningForTooLongSyncWorkloads):169 - Checking for sync workloads running for too long with timeout value PT720H 2026-04-10 165410,811 [scheduled-executor-thread-9] INFO i.a.c.j.WorkloadMonitor(cancelRunningForTooLongNonSyncWorkloads):148 - Checking for workloads running for too long with timeout value PT4H 2026-04-10 165410,811 [scheduled-executor-thread-6] INFO i.a.c.j.WorkloadMonitor(cancelNotHeartbeatingWorkloads):120 - Checking for non heartbeating workloads. 2026-04-10 165410,815 [scheduled-executor-thread-7] INFO i.a.c.j.WorkloadMonitor(cancelNotClaimedWorkloads):93 - Checking for not claimed workloads.

New message text here

@kapa.ai, please provide a step-by-step guide. The database is one of the pods, correct?

New message text here

@kapa.ai, I think, this is the right culprit. Now I get: "Failed to save Postgres due to the following error: Could not connect with provided configuration. Error: HikariPool-1 - Connection is not available, request timed out after 30000ms (total=0, active=0, idle=0, waiting=0)" This might be a mismatch in host and port.

Great progress! The 502 error is gone, which means the pod is now being spawned and the workload is reaching the connector. The new error is a Postgres connection failure from the connector to your target database — this is a different, more straightforward problem. The error

HikariPool-1 - Connection is not available, request timed out after 30000ms

means the Postgres destination connector cannot reach your Postgres instance. [Source Postgres connection error] Common causes and fixes 1. Host configuration Since your Postgres instance is running as a Docker container and Airbyte is running inside a kind cluster (also inside Docker),

localhost

or

127.0.0.1

will not work — they refer to the connector pod itself, not your host machine or your Postgres container. • If your Postgres container is on the same Docker network as the kind cluster, use the container name as the hostname. • If it's on a different network, use

host.docker.internal

(on Mac/Windows) or the Docker bridge IP (typically

172.17.0.1

on Linux). [external Postgres connection] 2. Port Make sure the port you're entering matches what your Postgres container is actually listening on and has exposed. The default is

5432

, but if you mapped it to a different host port, use the container port (not the host-mapped port), since you're connecting container-to-container. [Postgres destination setup] 3. Postgres must accept remote connections Your Postgres 18 instance must be configured to accept connections from outside

localhost

. Check: • `postgresql.conf`:

listen_addresses = '*'

• `pg_hba.conf`: has a rule allowing connections from the Airbyte connector's IP range [external Postgres connection] 4. Credentials and database name Double-check that the username, password, and database name are correct and that the user has the necessary permissions:

CREATE USER airbyte_user WITH PASSWORD '<password>';
GRANT CREATE, TEMPORARY ON DATABASE <database> TO airbyte_user;

[Postgres destination setup] Quick diagnostic To test connectivity from within the cluster, you can run a temporary pod:

kubectl run -it --rm pg-test --image=postgres:15 -n airbyte-abctl -- \
  psql -h <your-postgres-host> -p 5432 -U <user> -d <database>

If this fails, the network path is the issue. If it succeeds, the problem is in the connector configuration. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.