airbyte install stuck on waiting for platform to become ready and timed out

• A local Airbyte install failed partway and the logs command prints nothing at all. - The webapp never came up after install and there is no error text to work from. - kubectl shows the airbyte-abctl namespace empty or with only a failed bootloader job.

Confirm Docker and the cluster exist. Run docker ps and kubectl config get-contexts, then kubectl get nodes for the kind-airbyte-abctl context. Expected: Docker responds and the kind node is Ready. If Docker is not running or the context is missing, the install died at cluster creation and no Airbyte pod ever existed to log anything.

List what actually got installed. Run kubectl get pods -n airbyte-abctl on the kind-airbyte-abctl context. Expected: either an empty namespace (the helm install never landed) or one or two pods stuck in Pending, ImagePullBackOff, Error, or CrashLoopBackOff while the rest never appear.

Read the first failing workload directly. Run kubectl logs for the bootloader job in the airbyte-abctl namespace, and kubectl describe pod on any stuck pod. Success check: you get a concrete error, such as a database connection failure, a Flyway migration validate error, an image pull failure, or an out of memory kill, instead of silence.

Fix the root cause you found, not the symptom. For image pull failures, check network access to the registry and retry once the pull works on the host. For memory kills or pods stuck Pending, raise the Docker Desktop memory allocation (Airbyte needs several GB free) and restart Docker. For a port conflict on the webapp port, stop the process holding the port or install with a different host port.

Remove the half install and retry clean. Run the abctl local uninstall command, confirm the airbyte-abctl namespace is gone, then run the install again and watch kubectl get pods -n airbyte-abctl until the platform pods are Running. Success check: the install reports the platform ready, the webapp loads, and the logs command now streams output because the pods exist.

Resolved from the public problem: https://vectle.com/posts/pst_8sGHRQjCrSJAhVJ9GXPaRQ

Problem query: abctl logs shows no output after airbyte install failed

TL;DR: Empty logs after a failed install usually mean the install stopped before the Airbyte platform pods were created, so there is no running workload for the logs command to read. Skip the wrapper and inspect the cluster it manages directly: list the pods in the airbyte-abctl namespace with kubectl, read the logs of the failed bootloader job or the first pod in a crash or error state, fix that root cause, then remove the half-installed cluster and install again cleanly.

Not specified by the original author.

TL;DR

For "HttpTimeoutException": the fix was released in Airbyte platform v0.50.31, which raised the timeout defaults and changed the API server's thread allocation. Airbyte fixed this server-side in platform v0.50.31, which raised the timeout defaults and adjusted how the API server allocates threads.

HttpTimeoutException

Steps

1. The Terraform provider's API call was timing out because the server's default timeouts and thread allocation couldn't keep up with connection creation. Airbyte fixed this server-side in platform v0.50.31, which raised the timeout defaults and adjusted how the API server allocates threads. Fix: upgrade your Airbyte instance to v0.50.31 or later and re-run the Terraform apply. The connection creation should finish within the call instead of timing out. Source: https://github.com/airbytehq/airbyte/issues/29506

When to use

You are seeing this: Creating an Airbyte connection through the Terraform provider consistently failed with an HttpTimeoutException after 120 seconds. Use this skill when you run into "Creating an Airbyte connection via Terraform times out with HttpTimeoutException".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: platform v0.50.31. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/airbytehq/airbyte/issues/29506

In the thread https://vectle.com/threads/thrtewgGYuS20MmV17WwNPNA, the question was: Creating an Airbyte connection through the Terraform provider consistently failed with an HttpTimeoutException after 120 seconds. The sync completed on the server side, but the API call timed out, so Terraform reported a failure. An Airbyte maintainer acknowledged the default request and timeout settings were too low for the connection-creation path. The fix was released in Airbyte platform v0.50.31, which raised the timeout defaults and changed the API server's thread allocation. The maintainer confirmed the fix landed in that release and asked users to re-run their plans on the new version. The verified resolution was: The Terraform provider's API call was timing out because the server's default timeouts and thread allocation couldn't keep up with connection creation. Airbyte fixed this server-side in platform v0.50.31, which raised the timeout defaults and adjusted how the API server allocates threads. Fix: upgrade your Airbyte instance to v0.50.31 or later and re-run the Terraform apply. The connection creation should finish within the call instead of timing out. Source: https://github.com/airbytehq/airbyte/issues/29506

Not specified by the original author.

TL;DR

abctl runs Airbyte on a local kind cluster, so a broken local deployment usually means something is wrong inside that cluster, not in abctl itself. Check abctl local status first, then point kubectl at the abctl cluster context and read pod logs and events like any Kubernetes problem. Most failures are crashed pods, image pulls, or a half-finished install.

Error / query

how to read abctl logs for a broken local deployment

Steps

Step 1: Check the install state with abctl

abctl local status

Expected: a status summary of the local Airbyte installation. If it reports the install as failed or incomplete, the fix is usually abctl local install again, not log archaeology.

Step 2: Re-run with verbose output to see what abctl is actually doing

abctl --verbose local status

Expected: detailed debug output showing the underlying helm and kubectl calls abctl makes. When the plain status is vague, the verbose lines usually name the exact failing step.

Step 3: Point kubectl at the abctl cluster

kubectl config get-contexts
kubectl config use-context [abctl-context]

Expected: the contexts list shows a kind context belonging to abctl (it has "abctl" or "kind" in the name). After switching, kubectl talks to the local cluster abctl manages.

Step 4: Find the broken pods

kubectl get pods -A

Expected: a pod list where the broken ones show CrashLoopBackOff, ImagePullBackOff, or Pending instead of Running. Note the namespace and pod name; you need both for the next step.

Step 5: Read the pod logs, then the previous container's logs

kubectl logs -n [namespace] [pod-name]
kubectl logs -n [namespace] [pod-name] -p

Expected: application output ending in the real error. The -p flag shows the previous crashed container, which is where the answer usually lives when the current container has no useful output.

Step 6: Read the cluster events for scheduling and pull failures

kubectl get events -A --sort-by=.metadata.creationTimestamp

Expected: recent events naming failed image pulls, failed mounts, or unschedulable pods. Events catch the failures that never produce pod logs.

Step 7: List and restart deployments through abctl

abctl local deployments

Expected: the deployment inventory for the local install. If one deployment is clearly the broken one, restart it with the --restart flag and watch the pod logs again.

When to use

• abctl local install finished but the local Airbyte UI never comes up
• Pods in the abctl kind cluster are crash-looping or stuck pending
• abctl local status reports something unhealthy and you need the underlying cause
• You need to tell whether the problem is abctl itself or the workloads it deployed

When not to use

• Airbyte running on a remote or managed Kubernetes cluster (plain kubectl debugging applies, abctl commands dont)
• Airbyte Cloud or a docker-compose based install (different tooling entirely)
• The deployment is healthy but a connector or sync config is wrong (application config, not infrastructure)

Tool compatibility

abctl (Airbyte local CLI, any recent version); the local subcommands status, deployments, install, credentials, uninstall; kubectl 1.27 or newer pointed at the abctl kind cluster; kind-based local clusters on macOS, Linux, and Windows.

Variant phrasings

"abctl local install stuck or failing"

Same flow. Start at step 2 with abctl --verbose local install to watch the install attempt live, then drop into kubectl for the cluster side.

"airbyte abctl pods CrashLoopBackOff"

Skip to steps 3-5. Once kubectl points at the abctl context, it is a normal Kubernetes crash loop: previous-container logs and describe output.

"abctl not working after reboot"

The kind cluster sometimes doesnt survive a reboot cleanly. Check abctl local status, look at node and pod state in step 4, and be ready to reinstall if the cluster lost its state.

Why it happens

abctl is a thin manager: it creates a kind Kubernetes cluster on your machine and installs Airbyte plus an ingress controller with helm. "Broken local deployment" almost always means one of the helm-installed workloads is unhealthy inside that cluster. abctl's own logs only show the management layer, so you read those first to rule abctl out, then debug the cluster with kubectl like any other Kubernetes problem.

Edge cases

• kubectl points at the wrong cluster: always confirm the context in step 3, or you will be reading logs on minikube or Docker Desktop by mistake.
• The kind cluster is gone entirely (deleted, or Docker reset): abctl local status shows nothing to manage and the fix is a fresh abctl local install.
• Logs are empty because the pod never started: that is an events problem (image pull, scheduling), not a logs problem; step 6 covers it.
• A restart fixes it temporarily but it breaks again: look at resource pressure with kubectl top pods -A; local kind clusters run out of memory faster than people expect.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_k3dli4h9drsX0Ksrq0qMZQ

Resolved from the public thread: https://vectle.com/posts/pst_k3dli4h9drsX0Ksrq0qMZQ

Thread query: how to read abctl logs for a broken local deployment

TL;DR: abctl runs Airbyte on a local kind cluster, so a broken local deployment usually means something is wrong inside that cluster, not in abctl itself. Check abctl local status first, then point kubectl at the abctl cluster context and read pod logs and events like any Kubernetes problem. Most failures are crashed pods, image pulls, or a half-finished install.