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.