kubectl get events sorted by time

kubectl get events --sort-by='.lastTimestamp' puts the newest cluster event last instead of dumping them in whatever order the API returned. Events are the first place to look, before logs — logs tell you what your application did, events tell you what the cluster did to it. Half the failures worth caring about (no disk space, an image that won't pull, missing resources, a volume that never mounted) never show up in a log at all.

1. How do you sort kubectl events by time?

$ clai show cluster events, newest at the bottom→ kubectl get events --sort-by='.lastTimestamp'

Without sorting, events come back in whatever order the API happens to store them, which makes them useless to scan. The sort key starts with a dot because it's a JSONPath into the event object.

2. How do you see only warnings in one namespace?

$ clai show warnings in the production namespace from recently→ kubectl get events -n production --field-selector type=Warning --sort-by='.lastTimestamp'

Events come in two types, Normal and Warning. Normal only adds noise while you're triaging an incident. --field-selector filters server-side, so it stays fast even on a large cluster.

3. How do you see the events for one pod?

$ clai show what happened to this pod→ kubectl describe pod my-app-7d9f8 -n production

describe prints events at the bottom of its output, already scoped to the object — usually faster than filtering the full event list. That's where you'll spot reasons like FailedScheduling, ImagePullBackOff, or OOMKilled.

4. How do you get the logs of a crashed container?

$ clai show logs from the previous run of this container→ kubectl logs my-app-7d9f8 -n production --previous

When a container restarts, its logs get replaced by the new instance's. --previous pulls the prior instance's logs — the ones that actually recorded why it died. Skip the flag and you're staring at a freshly started process with nothing to say yet.

5. How do you watch events live?

$ clai watch events in this namespace right now→ kubectl get events -n production --watch

Useful during a rollout: you watch the scheduler place pods, images pull, and readiness checks pass in real time. Ctrl+C to stop.

6. Why is a pod not starting?

$ clai show pods that aren't running, and their events→ kubectl get pods -n production --field-selector status.phase!=Running

Narrow to the broken pods first, then describe each one. Pending almost always means the scheduler has nowhere to put the pod — not enough resources, placement constraints that don't match, or a volume it couldn't find.

Gotchas

• Events last about an hour. --event-ttl defaults to 1 hour, and after that the event is gone. There's nothing left to replay yesterday's incident from — you need an external collector.
• --sort-by needs a JSONPath with a leading dot. --sort-by='.lastTimestamp', not lastTimestamp. Leave off the dot and the command silently returns an unsorted list.
• Events are namespaced. Without -n you're looking at the default namespace and seeing nothing from production. Use --all-namespaces for the full picture.

Related questions

Logs or events — where do you start? Events. They tell you whether the application even got to start. Logs only matter once the container is actually running.

Why is kubectl logs empty? Either the container never started, it's not writing to stdout, or it already restarted. Events answer the first two; the --previous flag answers the third.

How is kubectl events different from kubectl get events? The standalone kubectl events command showed up later and sorts by time by default. get events works everywhere, including older clusters.

See also

• Docker and Kubernetes muscle memory, replaced
• Docker ate your disk
• Read a service's logs with journalctl

CliAI turns a plain-English question about a pod into the right kubectl command, without you memorizing field selectors or JSONPath syntax. Install it in one line.