## 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
```text
how to read abctl logs for a broken local deployment
```

## Steps

### Step 1: Check the install state with abctl
```bash
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
```bash
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
```bash
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
```bash
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
```bash
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
```bash
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
```bash
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