kubectl events: Usage, Options & Common CI Errors
See what the controllers are saying - sorted and filterable.
kubectl events lists Event objects - the breadcrumbs schedulers, kubelets, and controllers leave. The dedicated command (newer than kubectl get events) adds proper chronological sorting and per-object scoping that make CI failures legible.
What it does
kubectl events lists events newest-relevant first, with --for to scope to a single object (--for pod/my-pod), --types=Warning to filter severity, and --watch to stream. It is more readable than kubectl get events for debugging because the time ordering and object scoping are built in.
Common usage
kubectl events --for pod/my-pod
kubectl events -A --types=Warning
kubectl events --for deploy/web --watch
kubectl get events --sort-by=.lastTimestamp # older equivalentCommon errors in CI
The defining gotcha is retention: Events default to a ~1 hour TTL, so a job that retries for a while and then dumps events finds the original failure already gone. Capture events immediately on failure, not after backoff. kubectl events is a relatively new subcommand; on older kubectl/cluster versions it does not exist ("unknown command \"events\"") and you must fall back to kubectl get events --sort-by=.lastTimestamp. Events are namespaced, so without -n or -A you only see the current namespace.
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.
# 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