kubectl get events -w: Usage, Options & Common CI Errors
Watch cluster events stream in as a deploy unfolds.
kubectl get events -w streams events as the cluster emits them, so you can watch scheduling, image pulls, and probe failures happen in real time. In CI it is a live window into why a deploy is stalling.
What it does
kubectl get events -w opens a watch and prints new events as they arrive. --field-selector narrows to one object or type (involvedObject.kind=Pod), and --sort-by=.lastTimestamp orders a one-shot listing chronologically. -A spans all namespaces. The newer kubectl events command offers the same with nicer formatting.
Common usage
kubectl get events -w
kubectl get events --sort-by=.lastTimestamp
kubectl get events --field-selector involvedObject.name=my-pod
kubectl get events -w --field-selector type=WarningCommon errors in CI
Events are time-boxed - the default retention is about one hour, so in a slow pipeline the events that explain an early failure age out before a later step reads them; capture them at the moment of failure, not after retries. -w runs forever and never exits on its own, so in CI you must background it and kill it (or use a one-shot --sort-by listing) or the step hangs. Sorting needs the one-shot form: --sort-by does not combine with -w. Events are best-effort and can be coalesced or dropped under load, so absence of an event is not proof nothing happened.
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