An incident from yesterday almost always leaves fewer traces than expected: Kubernetes Events, often the first resource checked to understand what happened, vanish by default after one hour, not a day or a week. Looking for yesterday’s event in kubectl get events is looking for data that’s already been purged.

What an Event actually is, and who emits it

An Event isn’t an application log or an API request audit record: it’s a structured notification emitted by the kubelet or a controller to signal a state change (Scheduled, Pulled, Started, Failed, BackOff). Every Event gets stored in etcd like any other Kubernetes resource, which explains why an aggressive retention policy exists: without it, the volume of Events continuously generated by an active cluster would eventually saturate etcd.

# Most recent events first,
# the first diagnostic command after an incident
kubectl get events --sort-by='.lastTimestamp'

The default TTL: one hour, configurable on the API server

--event-ttl on the API server sets Events’ retention duration, one hour by default. A Failed Event emitted at 2:00 PM explaining an incident that happened at 2:05 PM has a good chance of already being gone by 3:30 PM, when someone finally starts investigating after noticing a problem later.

# Adjustable via API server configuration,
# rarely changed from default despite this cost
--event-ttl=1h0m0s

Raising this TTL has a real cost in etcd volume, which explains why the default stays short rather than being extended out of caution: every state change of every pod, for every container, generates an Event, a volume that grows fast on a cluster with heavy deployment activity.

Why Events never replace audit logging

An Event answers “what happened to this pod, from the kubelet or a controller’s point of view.” Audit logging answers a different question: “who called the API, and with what request.” The two mechanisms coexist without substituting for each other: an Event never says who triggered the deployment that created the pod, and the audit log never says the pod failed to start three times before succeeding.

Exporting Events to outlast the one-hour window

An event exporter (like kube-eventer or a native integration with the observability stack) captures every Event at the moment it’s emitted and forwards it to an external logging system (Loki, Elasticsearch), before the TTL removes it from etcd. Once exported, the Event survives indefinitely, at the target logging system’s retention duration, not etcd’s.

# An exporter captures every Event at the moment
# it's emitted, before the TTL wipes it from etcd
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-event-exporter

This exporting turns a one-hour memory into a queryable history weeks later, an investment worth making the moment a post-mortem needs to precisely reconstruct what happened to a pod days after the incident.

Takeaway

A Kubernetes Event vanishes after one hour by default, a deliberately short retention policy to limit volume stored in etcd, which often means the proof of yesterday’s incident is already purged by the time anyone looks for it. Events and audit logging answer two different questions (an object’s state versus who called the API) and never substitute for each other. Exporting Events to an external logging system before they expire turns this short memory into a durable history, a habit that matters the moment a post-mortem needs to reach back past the last hour, one of the observability details separating genuinely usable reliability and observability from merely temporary access to information.