# kubectl logs: Command Reference for CI/CD

> Reference for kubectl logs: stream container output, read previous-container logs for crash loops, select containers, and bound output in CI.

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

Read the container output that explains the failure.

kubectl logs prints or follows a container stdout/stderr. The --previous flag, which shows the last crashed instance, is the single most useful option for debugging CrashLoopBackOff in CI. This reference lists the selection and bounding flags.

## Common flags and usage

- -f, --follow: stream live output
- -p, --previous: read the prior crashed instance log
- -c <container>: pick a container in a multi-container pod
- --all-containers: concatenate every container log
- --tail=N / --since=10m: bound how much output you fetch
- --timestamps: prefix each line with an RFC3339 timestamp

## Example

```shell
# On crash, dump the previous instance's log for triage
kubectl logs deploy/web --tail=200 --timestamps || true
kubectl logs my-pod --previous --tail=100
```

## In CI

For a pod stuck in CrashLoopBackOff, the current log is often empty because the process died instantly; --previous reads the last crashed instance. Always bound with --tail or --since so a chatty container does not flood the job log.

## 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: Command Reference for CI/CD?

kubectl logs prints or follows a container stdout/stderr. The --previous flag, which shows the last crashed instance, is the single most useful option for debugging CrashLoopBackOff in CI. This reference lists the selection and bounding flags.

### In CI?

For a pod stuck in CrashLoopBackOff, the current log is often empty because the process died instantly; --previous reads the last crashed instance. Always bound with --tail or --since so a chatty container does not flood the job log.

---

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