Cleanup

Cleanup

Cluster → Cleanup lists objects that look unused or left over — claims no Pod mounts, Released volumes, Services without endpoints, old ReplicaSets, finished Pods and Jobs, empty namespaces, and (if you turn them on) ConfigMaps and Secrets nothing refers to — each with why it looks unused, how long it has been that way and what deleting it would touch. You can then delete the ones you choose in one go.

Deleting is the one thing in Sextant that removes many objects at once, and Kubernetes has no undo. So the page is deliberately conservative: when in doubt, an object is not offered. It will show you less than a script would, and it tells you why for the rest.

Contents: What Sextant will never offer for deletion, and why · What it looks for · Using the page · Deleting · Settings · Limits

What Sextant will never offer for deletion, and why

These rules are fixed. They are not settings, and they will not be relaxed without a review.

Never offered	Why
ConfigMaps and Secrets, unless you turn them on	References to them hide in places Sextant cannot see: operators and custom resources, CSI drivers, controller command-line flags, applications that read them through the API. A missing Secret usually fails late — at the next restart or reconcile, far from the cleanup. Both rules are off by default; the settings warn you before you turn them on.
Anything in a namespace that holds custom resources Sextant does not read	Any operator's resource can name a ConfigMap, Secret or claim in a field Sextant does not know. When a namespace holds such objects, its ConfigMaps, Secrets and PersistentVolumeClaims are not judged, and the page names the kinds that blocked it.
A namespace that is not completely empty	An empty namespace is offered only if every kind the cluster serves holds nothing in it but what Kubernetes creates in every namespace (the kube-root-ca.crt ConfigMap, the default ServiceAccount and its token). Sextant checks this with a quick names-only look at every kind, custom ones included; if any kind cannot be read, the namespace is not offered. Deleting a namespace deletes everything in it.
Released volumes with reclaim policy Retain	Retain is a deliberate choice to keep the data. Such volumes are shown under Kept on purpose without a checkbox.
Objects a tool manages (Helm, Flux, Argo CD, anything with app.kubernetes.io/managed-by)	The tool would create them again or lose track of them. They are listed under Managed by a tool with the tool's name: remove them through the tool.
Objects with an owner	Their owner decides their life; deleting them by hand fights the controller.
Built-in and bookkeeping objects	kube-root-ca.crt and similar distributed ConfigMaps, leader-election ConfigMaps, service account token Secrets, Helm release Secrets, Argo CD Secrets, the default/kubernetes Service, ExternalName Services.
Pods of a Job or of an unknown controller; Jobs of a CronJob or with ttlSecondsAfterFinished	Their controller cleans them up.
Anything in kube-system, kube-public, kube-node-lease or a namespace you excluded; the namespaces default and kube-* themselves	System namespaces are never checked, and several tool namespaces are excluded by default; you can exclude more (see Settings).
Anything a list Sextant could not read fully might refer to	If a list that could name an object is forbidden, failed or still loading, the object is not judged, and the page says which lists were missing.
Objects being deleted, or too young	An object must have been unused for a number of days you set per rule.

And whatever you select, each object is checked again right before it is deleted, and the API server is told to delete it only if it is still exactly the object you confirmed (its uid and resourceVersion). An object that was replaced, changed or started being used again in the meantime is kept. See Deleting.

AI agents (through the MCP server) and Extensions get nothing from this page: there is no bulk delete for them.

What it looks for

Rule	Offered when	Age counts from
ConfigMaps nothing uses (off by default)	No Pod or pod template mounts it or reads it for environment variables, no container argument or environment value names it (ns/name or the name in its own namespace), and no object of a known tool names it	created
Secrets nothing uses (off by default)	As above, plus no ServiceAccount, Ingress TLS or ingress-nginx auth annotation, Gateway listener or ReferenceGrant, StorageClass secret parameter or PersistentVolume secret reference names it, and no cert-manager, Flux, KEDA, External Secrets, Prometheus operator, Velero, Istio or Traefik object does	created
PersistentVolumeClaims no Pod mounts	No Pod mounts it and no pod template, StatefulSet claim template, VolumeSnapshot or other claim's data source names it. The row says the reclaim policy of its volume: Delete means the data goes with it	created
Released or unclaimed PersistentVolumes	Released (its claim was deleted) or Available and bound to no claim — except Released with Retain, see above	in this phase
Services without endpoints	No endpoints, and its selector matches no Pod and no pod template; a Service without a selector also has no manual Endpoints	created
Old ReplicaSets	Scaled to 0 and beyond its Deployment's revisionHistoryLimit	created
Finished Pods	Succeeded or Failed and not owned by a Job	finished
Finished Jobs	Completed or Failed, not owned by a CronJob, without ttlSecondsAfterFinished	finished
Empty namespaces	See above: every served kind empty of anything but the Kubernetes defaults; never default or kube-*	created

Each row also shows what the Resource map says deleting it would do ("If deleted").

Using the page

1. Choose namespaces in the namespace filter: the page checks the first 5 of them (with All namespaces it asks you to choose). Excluded namespaces in the filter are named and skipped.
2. Wait for Reading the namespaces… to finish. The page reads the lists it needs and takes a names-only look at every kind in each namespace. Check again repeats that look.
3. Candidates are grouped by rule. Open an object with its name; tick objects one by one or a whole group with the checkbox in its heading.
4. Below the candidates: Managed by a tool, not offered for deletion and Kept on purpose, not offered for deletion, and notes about namespaces that were blocked by unknown kinds or lists that were not read in full.

The page only reads the cluster until you press Delete selected.

Deleting

Delete selected (N)… opens a confirmation that lists every object, grouped by kind. If a namespace is among them, it warns that deleting a namespace deletes everything in it, including kinds this page does not check. Above 20 objects you must type the number to confirm.

After you confirm:

• Sextant waits a second, so that anything created just before your click (a new Pod mounting a ConfigMap) has reached the page.
• It deletes one object at a time, namespaces last. Right before each one it checks that the object is still a candidate with the same uid and resourceVersion you confirmed, and the delete request carries both as preconditions, so the API server refuses if the object changed.
• A refusal (no permission, a conflict, a timeout) is that object's result; the run goes on. A delete is never repeated automatically.
• Stop finishes the object being deleted and tries no more.

The result lists every object: Deleted, Already gone, Kept: no longer looks unused, Kept: changed since it was checked, Failed (with the reason) or Not tried: stopped.

Settings

Settings… on the page (saved in settings.json, see Settings):

Setting	Default
Offer ConfigMaps nothing seems to use	off
Offer Secrets nothing seems to use	off
Namespaces never checked (one per line; kube-system, kube-public and kube-node-lease are always skipped)	cert-manager, flux-system, argocd, ingress-nginx, istio-system, monitoring, local-path-storage
Offer only objects older than this, in days — ConfigMaps and Secrets, Services, finished Pods, finished Jobs	7 days each
— PersistentVolumeClaims, PersistentVolumes (days in their phase), empty namespaces	30 days each

Limits

• At most 5 namespaces at once. PersistentVolumes, Namespaces and StorageClasses are read cluster-wide while the page is open; everything is read with your permissions, and a list you may not read makes the objects that depend on it "not judged".
• A referrer created during a deletion run cannot be ruled out by any check before a delete; the per-object re-check and the preconditions narrow it. That is one more reason ConfigMaps and Secrets are off by default.
• Sextant does not know what your applications do at runtime. Check each ConfigMap and Secret before deleting it.

Next: Using Sextant.