Timeline

Timeline is a single activity stream for any object: it fuses every time-stamped signal Buoy can gather — Kubernetes events, container restarts and state changes, condition transitions, rollout revisions, node conditions — into one vertical canvas you read top to bottom. It is a tab on the detail view of every kind. At minimum each object shows its events; Pods, Namespaces, and Nodes layer extra signals on top.

Timeline replaces the old standalone Events tab. Everything the events table showed is here, plus more.

Contents

• Where It Shows Up
• Reading the Canvas
• Controls
• Worked Examples
• A Note on Event Retention

Where It Shows Up

On a Pod, the Node lanes are visually separated from the pod’s own lanes with a divider — they describe the host, not the pod, and the divider keeps that distinction obvious.

Reading the Canvas

A vertical spine runs down the left with now pinned at the top. Cards stack newest-first, and the gap between them is scaled to the real time delta, so bursts cluster tightly and quiet stretches don’t waste space.

• Spine — the timeline runs down the left edge; now is at the top.
• Source color — each source gets a stable accent color, drawn as a left-edge stripe on its cards and used to tint its chip. Cards from the same source group by color even when interleaved.
• Severity dot — green is success (Ready, Completed, Running), blue is informational, yellow is a warning (e.g. ImagePullBackOff), red is an error (failed events, NotReady, CrashLoopBackOff).
• Title — the event reason (Started, BackOff, Ready = True) or, for container milestones, <container> · <state>.
• Source chip — tells you which lane produced the row (Pod Events, Pod Lifecycle, Node Conditions, the kind name for namespace sources).
• Message excerpt — the first line of the full message. Click a card to expand it for the full message and metadata.
• Relative time — on the right; hover for the exact timestamp.
• Burst cards — when several events from the same lane fire within seconds, they collapse into one card showing the most recent title plus +N More and the worst severity. Click to expand the whole burst.
• Gap pills (··· 47m Gap) — replace long empty stretches with a single row that labels how much time passed.
• Truncation footer — appears at the bottom of a lane when there were more events than Timeline loaded; the visible history is bounded by what the cluster still retains (see retention).

Controls

A single toolbar runs across the top:

• Search — free text over event titles and messages.
• Severity filter — All / Warnings / Errors.
• Range — Last 15m / Last 1h / Last 6h / Last 1d / All. This sets both the visible window and how densely time is drawn.
• Sources — a checkbox list of every lane; the button shows how many are visible. A red badge means a lane errored (for example, you can read pod events but not node events); hover the affected lane for the message. The rest of the timeline keeps streaming.
• Live / Paused — pausing freezes the now anchor so the layout doesn’t shift while you read.

Worked Examples

Why is my pod in CrashLoopBackOff?

Open the failing pod → Timeline.

• The lifecycle lane shows a red dot for each restart, with a count badge that climbs every retry. Click one to read the termination reason (e.g. OOMKilled, Exit 137).
• The pod events lane shows the matching BackOff warning each interval.
• The node events lane (below the divider) is the tiebreaker: if SystemOOM or NodeNotReady shows up around the same times, the failure is the node, not the pod.

It’s resolved when the last restart dot is older than the current Running marker and no new red dots appear while following live.

Did Karpenter consolidate a node out from under my pod?

Open the pod that disappeared (or the controller’s most recent child pod) → Timeline.

• A Killing immediately followed by FailedScheduling is the disrupt-and-replace signature.
• Switch to the owning workload, then to its newest pod — its timeline should show it Scheduled to a different node.
• For the host’s side of the story, open the old node by name (nodes <name>) → Timeline and look for the NodeNotReady → Ready=Unknown → Deleted sequence on its conditions lane.

If you run Karpenter, its disruption events on the node surface here too.

When did the HPA scale this deployment up?

Open the Namespace that owns the workload → Timeline.

• The HorizontalPodAutoscaler lane shows a marker for each rescale, with the replica delta in the message.
• The Deployment lane shows the corresponding scaling markers a few seconds later.
• The Pod lane fills with Scheduled / Pulled / Started as new pods come up.

Read left-to-right and you get the cause-and-effect chain — HPA → Deployment → ReplicaSet → Pods — all on one wall clock.

Did the node go under pressure before or after my pod was evicted?

Open the pod → Timeline.

• The pod events lane shows the eviction (Evicted, Killing).
• Below the divider, the node conditions lane shows the MemoryPressure: False → True transition.
• Their relative position on the time axis answers the question: pressure before the eviction means the node was the trigger; pressure after means the eviction came from somewhere else (priority preemption, disk admission, …) and you should keep digging in the event lanes.

A Note on Event Retention

Kubernetes events are not a durable audit log — the cluster expires them on a TTL (often under an hour on busy clusters). Timeline shows everything the cluster still has, and is explicit about the edges:

• When a lane has older events than the cluster kept, Timeline draws a hatched zone at the start of that lane with a “pruned” marker. Read it as “there was more history here, but it’s gone.” Timeline never silently pretends to show more than it can.
• A long visible history does not mean the cluster is healthy — it can just mean a slow event stream.

If you need older history than the cluster retains, raise --event-ttl on the API server, or ship events to a long-term store (Loki, Elasticsearch, …). Timeline can’t conjure history that isn’t there.

Edit this page on GitLab