# kubectl get events -w: Usage, Options & Common CI Errors

> kubectl get events -w streams cluster events live. Watching a deploy unfold, sorting and field-selecting, and the event-TTL gotcha in slow CI.

Source: https://latchkey.dev/learn/command-reference/kubectl-get-events-watch  
Updated: 2026-06-25

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

```Terminal
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=Warning
```

## Common 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.

```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
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl get events -w: Usage, Options & Common CI Errors?

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 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.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt