Skip to content
LatchkeyLatchkey home

kubectl logs -l: Usage, Options & Common CI Errors

Tail logs from every pod behind a label in one command.

kubectl logs -l streams logs from all pods matching a label selector, so you can watch a whole Deployment's replicas at once. In CI it is how you collect aggregated output from a multi-replica workload after a test.

What it does

kubectl logs -l app=web selects every matching pod and multiplexes their logs. --prefix tags each line with its pod name, --all-containers includes sidecars, and --max-log-requests raises the cap on how many pods it will stream concurrently (default 5). --tail and --since bound the output.

Common usage

Terminal
kubectl logs -l app=web --prefix --tail=100
kubectl logs -l app=web --all-containers --since=10m
kubectl logs -l app=web --max-log-requests=20 --prefix
kubectl logs -l app=web -f --prefix              # follow all replicas

Common errors in CI

"error: you are attempting to follow ... pods, but maximum number of concurrent logs allowed is 5" hits when the selector matches more than 5 pods - raise --max-log-requests to cover the replica count. Without --prefix the interleaved lines lose which pod they came from, useless for debugging - always add --prefix when fanning out. A selector that matches zero pods prints nothing and exits 0, so a CI step that "collected logs" may have collected silence - assert the selector matched (kubectl get pods -l app=web) first. Each stream is a separate API watch, so very wide selectors are heavy.

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

Frequently asked questions

kubectl logs -l: Usage, Options & Common CI Errors?
kubectl logs -l streams logs from all pods matching a label selector, so you can watch a whole Deployment's replicas at once. In CI it is how you collect aggregated output from a multi-replica workload after a test.
What it does?
kubectl logs -l app=web selects every matching pod and multiplexes their logs. --prefix tags each line with its pod name, --all-containers includes sidecars, and --max-log-requests raises the cap on how many pods it will stream concurrently (default 5). --tail and --since bound the output.
Common errors in CI?
"error: you are attempting to follow ... pods, but maximum number of concurrent logs allowed is 5" hits when the selector matches more than 5 pods - raise --max-log-requests to cover the replica count. Without --prefix the interleaved lines lose which pod they came from, useless for debugging - always add --prefix when fanning out.

Related guides

References

Run this faster and cheaper on Latchkey managed runners - self-healing included. Start free → 30-day trial · No credit card