# kubectl logs: Usage, Options & Common CI Errors

> kubectl logs streams container logs. Previous-container logs for crash loops, multi-container selection, --since and --tail, and the errors you hit in CI.

Source: https://latchkey.dev/learn/command-reference/kubectl-logs  
Updated: 2026-06-25

Read the container output that explains the failure.

kubectl logs prints (or follows) a container's stdout/stderr. The --previous flag, which shows the log of the last crashed instance, is the single most useful option for debugging CrashLoopBackOff in CI.

## What it does

kubectl logs POD streams the current container's output. For multi-container pods use -c to pick one, or --all-containers. --previous (-p) reads the prior, crashed instance's log - essential when a container restarts before you can attach. --since, --tail, and --timestamps bound and annotate the output.

## Common usage

```Terminal
kubectl logs my-pod -f                 # follow live
kubectl logs my-pod -c sidecar         # a specific container
kubectl logs my-pod --previous         # the last crashed instance
kubectl logs -l app=web --tail=100 --timestamps
kubectl logs deploy/web --since=10m
```

## Common errors in CI

"previous terminated container ... not found" means the container has not restarted (so there is no previous log) or the node already rotated it away - read the current log instead. "a container name must be specified for pod X" appears on multi-container pods; pass -c or --all-containers. In CI, also watch for empty output when you log a Deployment that has rolled to a new ReplicaSet: kubectl logs deploy/web targets the newest pod, so a just-replaced crashing pod may need an explicit pod name plus --previous.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl logs: Usage, Options & Common CI Errors?

kubectl logs prints (or follows) a container's stdout/stderr. The --previous flag, which shows the log of the last crashed instance, is the single most useful option for debugging CrashLoopBackOff in CI.

### What it does?

kubectl logs POD streams the current container's output. For multi-container pods use -c to pick one, or --all-containers. --previous (-p) reads the prior, crashed instance's log - essential when a container restarts before you can attach. --since, --tail, and --timestamps bound and annotate the output.

### Common errors in CI?

"previous terminated container ... not found" means the container has not restarted (so there is no previous log) or the node already rotated it away - read the current log instead. "a container name must be specified for pod X" appears on multi-container pods; pass -c or --all-containers.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt