$ kubectl get events -n payments --sort-by=.lastTimestamp
No resources found in payments namespace.kube-apiserver's --event-ttl defaults to 1h. After that, events are garbage-collected from etcd.
Kubernetes deletes events after an hour. Radar doesn't.
Every event and resource delta, captured via Watch the instant it fires - so “what changed right before this broke?” still has an answer when the pager goes off hours later.
“So raise --event-ttl.”
On managed clusters (GKE, EKS, AKS), you usually can't. On self-managed clusters you can - but events live in etcd, so raising the TTL inflates etcd and eventually hurts control-plane latency. The default is low on purpose: don't use your API server as an audit log. Radar captures events via Watch the moment they fire and keeps the history outside the control plane - whatever the API server deletes in an hour, Radar has already seen and kept.
Events with context, not just strings.
Every entry is structured: the involved object, the reason, the count, the first and last timestamps, the kubelet or controller that emitted it. Click into any entry and the resource detail opens with that resource's state at that moment - replica counts, labels, annotations, status conditions.
Structured entries are also what make the timeline filterable by reason and shareable by URL - the same view opens on the next engineer's screen.
{
"type": "Warning",
"reason": "OOMKilled",
"involvedObject": {
"kind": "Pod",
"name": "api-7d9f-k2pxq",
"namespace": "api"
},
"message": "Container api exceeded memory limit (512Mi)",
"firstTimestamp": "2026-03-10T14:01:47Z",
"count": 1,
"source": {
"component": "kubelet",
"host": "ip-10-0-4-212.ec2.internal"
}
}Why the timeline holds up.
Watch API, not polling
SharedInformers set up Watch connections against the apiserver. When an event fires, the informer fires a callback. Radar captures it before it's subject to TTL pressure.
Local or Cloud retention
In-memory by default - fast, fits the local use-case, gone on restart. --timeline-storage=sqlite persists to a local file so history survives between sessions. Radar Cloud adds cloud-backed retention up to one year.
Diffs, not blobs
Resource changes land as structured deltas - what fields moved, from what to what. That's how Radar can show you the exact ConfigMap edit that preceded the OOMKill, not just “something changed.”
Apache 2.0. Yours to inspect, fork, or self-host.
Radar's source is on GitHub. Every feature on this page is in the binary you install with brew install. No telemetry, no mandatory login, no cluster data out. The one outbound call is an anonymous version check when the UI opens. If we ever change that, you'll see it in a diff first.
Questions we get about the timeline.
What happens to Kubernetes events after the default 1-hour TTL?
Why not just raise --event-ttl?
Does Radar's timeline survive a restart?
Can I see what actually changed, not just that something changed?
Can I filter and share a specific timeline view?
Need the history shared and durable? Radar Cloud retains each cluster's timeline for up to a year, for the whole team.
More of what Radar does in the same binary.
Issues & root cause
Failures grouped by subject, folded to the cause, with blast radius.
Applications view
Workloads folded into the apps they form, with health rollups and env skew.
GitOps for Argo + Flux
Fleet + per-app diagnosis with field-level drift, controller attribution, and lifecycle awareness.
Live topology graph
Every resource and connection, laid out by ELK.js, updated via SSE.
Debug from the record, not from memory.
Every event and delta since Radar started watching - kept past the TTL, filterable, shareable.
Apache 2.0 OSS · Unlimited clusters self-hosted · Hosted free tier for up to 3 clusters