## TL;DR
`kubectl get events --sort-by=.lastTimestamp` gives you the cluster's own timeline, newest last, which is the fastest way to see what the control plane did and when. Add `--watch` to follow events live during a deploy, and `--field-selector` to cut noise. Remember events expire after an hour by default, so for anything older you need your monitoring stack, not kubectl.

## Error / query
```text
kubectl get events sorted by time: the flags that matter
```

## Use this skill when
- Reconstructing the sequence of a recent incident
- Watching what happens during a rollout in real time
- Filtering event noise in busy namespaces
- Correlating pod restarts with node or scheduler actions

## Not for this skill when
- You need application log content (use kubectl logs)
- The incident is older than the event TTL (use monitoring/audit logs)
- You need metrics over time (use Prometheus)

## Steps

### Step 1: Get time-sorted events for a namespace
```bash
kubectl get events -n [namespace] --sort-by=.lastTimestamp
```
Expected: events oldest to newest, with LAST SEEN and COUNT columns. The sort puts the story in order; without it, kubectl's default ordering hides the sequence.

### Step 2: Watch events live during an operation
```bash
kubectl get events -n [namespace] --sort-by=.lastTimestamp --watch
```
Expected: new events stream in as they happen. Run this in a second terminal while you deploy or debug; you see scheduler, kubelet, and probe events in real time.

### Step 3: Filter to the signals you care about
```bash
kubectl get events -n [namespace] --sort-by=.lastTimestamp --field-selector reason!=Unhealthy,involvedObject.name=[pod-name]
```
Expected: only events for that object, excluding the noisy reason. Useful filters: `type=Warning` for problems only, `reason=FailedScheduling` for scheduler issues, `reason=OOMKilling` for memory kills.

### Step 4: Get cluster-wide context when the namespace view is not enough
```bash
kubectl get events -A --sort-by=.lastTimestamp --field-selector type=Warning | tail -30
```
Expected: the last 30 warning events across all namespaces. Node-level events (pressure, NotReady) live outside your namespace; the `-A` view catches them.

## Variant phrasings

### "kubectl events sort by time"
`--sort-by=.lastTimestamp` is the flag. `.metadata.creationTimestamp` works too but lastTimestamp reflects the latest occurrence.

### "watch kubernetes events"
Add `--watch` to the sorted command (step 2) and keep it running during the operation.

## Why it happens
Events are the control plane's diary: the scheduler, kubelet, and controllers record every decision there. They are the highest-signal, lowest-effort timeline for anything that happened in the last hour, which is why reaching for them before logs usually shortens debugging.

## Edge cases and pitfalls
- Events expire (default 1h TTL); an incident from this morning may already be gone from kubectl. Export important timelines promptly.
- The COUNT column aggregates repeats; a single line with COUNT 400 means one repeating problem, not 400 separate ones.
- `--sort-by` needs the full field path with the leading dot; `--sort-by=lastTimestamp` without the dot fails.
- Very busy clusters rate-limit event creation; during storms, some events are dropped and the timeline has gaps.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pSTNr2jFj5jBjXZfKT1z7g