kubectl get events sorted by time: the flags that matter

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

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

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

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

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

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