@kapa.ai I see no logs in my Airbyte set up on Kubernetes and the connection pods (data plane) aren't starting, even though the schema set-up pods are running. How can I troubleshoot?

This is a known issue that can have a few different root causes. Here's how to troubleshoot: 1. Check Pod Status and Events Run these commands to get an overview of what's happening:

kubectl get pods -n airbyte
kubectl -n airbyte get events --sort-by='{.lastTimestamp}'

Look for pods stuck in

Pending

status — this often indicates a storage/volume provisioning problem (e.g., PVCs waiting for EBS volumes to be created). [EKS deploy issue] 2. Check the Dataplane Group Configuration (Most Likely Cause for v2) If you upgraded from Airbyte v1 to v2, a very common cause of jobs not launching pods is a mismatched

dataplane_group_id

in the workspace table. The default dataplane group name changed between versions. Fix: Add the following to your Helm values before upgrading:

global:
  dataplaneGroups:
    defaultDataplaneGroupName: "AUTO"

Or, if already on v2, set it to `"default"`:

global:
  dataplaneGroups:
    defaultDataplaneGroupName: "default"

You can also fix it directly in the database by updating the

dataplane_group_id

on the

public.workspace

table to match the enabled entry in

public.dataplane_group

. [services stuck issue] 3. Check the Correct Container for Logs Not all containers emit useful logs. For sync pods, check the

orchestrator

container — it aggregates all human-readable logs. For check/discover/spec pods, check the

sidecar

container. The

source

and

destination

containers have empty stdout (used for Airbyte protocol messages). [log collection docs] To inspect logs from the right container:

# Find workload pods
kubectl get pods -l airbyte=job-pod --all-namespaces

# Check orchestrator logs for sync pods
kubectl logs <pod-name> -c orchestrator -n <namespace>

# Check sidecar logs for check/discover pods
kubectl logs <pod-name> -c sidecar -n <namespace>

[verifying log collection] 4. Verify the Database Pod is Healthy If the

airbyte-bootloader

or other core pods can't connect to the database, jobs won't start. Check:

kubectl get pods -n airbyte | grep db
kubectl logs -n airbyte <airbyte-db-pod-name>
kubectl get endpoints airbyte-db-svc -n airbyte

[bootloader failed issue] 5. Increase MinIO Storage (if logs show "No logs available") If you see the log file path but the message "No logs available", you may need to increase the storage space for MinIO (the

/storage

path). [K8s no logs] Summary: The most common cause for connection pods not starting (while schema/discovery pods work) in Airbyte v2 is the

dataplane_group_id

mismatch after an upgrade. Start there first. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.