kubectl logs: Command Reference for CI/CD

By Daniel Zoghalchali·Latchkey

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

Key takeaways

--previous is essential for crash loops: it shows the dead instance.
Multi-container pods need -c or --all-containers.
Bound output with --tail/--since so CI logs stay readable.

Frequently asked questions

kubectl logs: Command Reference for CI/CD?

In CI?