# kubectl events: Usage, Options & Common CI Errors

> kubectl events lists cluster events with filtering and watch. Sorting chronologically, scoping to one object, and why events vanish before CI reads them.

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

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

```Terminal
kubectl events --for pod/my-pod
kubectl events -A --types=Warning
kubectl events --for deploy/web --watch
kubectl get events --sort-by=.lastTimestamp     # older equivalent
```

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

```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 events: Usage, Options & Common CI Errors?

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

---

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