Change timeline

Change timeline

The change timeline answers the first question of an incident: what changed before it broke? It lists the changes of objects in a cluster — what changed (field by field), when, and which program made it — and shows the problems and Warning events that began soon after each change.

It is read-only: nothing in the cluster is changed from it.

Contents: Where to find it · How changes are recorded · Who made a change · History before Sextant · Soon after this change · Keeping the timeline between restarts · Limits and privacy

Where to find it

• Cluster → Timeline: the changes in the namespaces chosen in the namespace filter (the page watches the first 3 of them while it is open), newest first. Filters: Kind, Changed by, Only changes before problems, and History before Sextant (see below). Refresh reads the cluster's history again; Clear recorded forgets what was recorded for this cluster (and empties its saved file, if you keep one).
• Changes tab in the details of any object (except Events): the changes of that one object, with its history from before Sextant.

Each entry says Created, Changed or Deleted, the object, the time, and the fields that changed, such as spec.template.spec.containers[web].image: nginx:1.25 → nginx:1.27. Long lists of changes are folded behind Show all changes.

How changes are recorded

Sextant does not open extra watches to record changes. It records what the views you already have open receive: resource tables, the problem watches behind the Problems page and notifications, the related-objects tab and map, and the Timeline page itself. So the timeline knows about the objects Sextant was watching while it was connected.

• A change is recorded when a newer version of an object differs from the one Sextant saw before. status, resourceVersion, generation, timestamps and annotations that controllers rewrite on their own (such as last-applied-configuration or deployment.kubernetes.io/revision) do not count; kubectl.kubernetes.io/restartedAt (a restart) does.
• Objects that change all the time on their own are not recorded, because their owner tells the story: Pods, ReplicaSets, ControllerRevisions, Events, Endpoints and EndpointSlices, Leases, and a CronJob's Jobs. A Deployment's rollout shows up as a change of the Deployment.
• Seen later: if nothing watched an object for a while, Sextant notices a change only when it lists the object again. The entry is marked Seen later: the change was made at some time before.
• Lists filtered by labels or fields are not used for recording, so an object that merely stops matching a filter is never shown as deleted.

Who made a change

Kubernetes records which program last wrote each field of an object (its field managers). After a change, Sextant reads the object's field managers and names those that wrote at that moment: By kubectl-client-side-apply, By helm, By argocd-controller… When no manager's time moved, the most recent writer is shown as Probably by …. Sextant (you or an AI agent) means the change was made through Sextant.

A field manager is a program name, not a person. Who ran the program is in the API server's audit log, which Sextant does not read.

History before Sextant

What happened before Sextant was running comes from what the cluster itself keeps, and is marked Partial:

• the last change of each field manager of each object (earlier changes by the same manager are not kept by Kubernetes);
• rollout revisions of Deployments, StatefulSets and DaemonSets, with their change cause;
• Helm release revisions, with their status.

Only names, managers, times and revision numbers are read — never an object's contents, a Secret's data or a Helm manifest. On the Timeline page this covers the first 10 namespaces of the filter; with All namespaces the page asks you to choose.

Soon after this change

Under a change, Soon after this change lists the problems (from the Problems and notifications rules) and Warning events that began from a minute before to 30 minutes after it, on the object itself or on what depends on it — the pods of a Deployment, the workloads that mount a ConfigMap, what a Service or an HPA picks. Only changes before problems shows only changes with such a follow-up.

This is a hint about timing, not proof of cause.

Keeping the timeline between restarts

By default the timeline lives only in memory: it starts empty each time Sextant starts and is gone when it quits.

Tick Keep between restarts on the Timeline page to keep it. Each cluster's recorded changes are then saved a few seconds after they change, in a file of their own in Sextant's data folder (timeline/, at most 8 MB per cluster, the oldest changes dropped first), and loaded the next time you connect. Unticking it removes all saved timeline files, also those of clusters you no longer have. See Settings.

Limits and privacy

• Secret values are never recorded. Sextant receives Secrets without their values; the timeline names the keys that changed and never a value, and the saved file is cleaned of values again when written and read.
• Memory is bounded: per cluster the latest 5000 changes (about 4 MB), and at most 20 000 remembered objects; very large objects, or too many of them, are remembered as a fingerprint only — a change is still noticed, but its fields are not known ("the earlier version was too large to keep").
• Namespaces no open view watched have no recorded changes, only the partial history.
• AI agents (through the MCP server) can read what the timeline already holds with the read-only get_recent_changes tool, only for objects their rules let them read, and a Secret's changes by key names only; the tool never opens a watch (see Diagnostic tools). They cannot save, load or remove the kept timeline. Extensions cannot read it.

Next: Using Sextant.