Problems and notifications

Problems and notifications

Sextant collects everything that is red in a cluster on one Problems page, counts it on the Cluster section, and can tell you with a desktop notification when something starts to fail while you work in another window.

Contents: Turning notifications off · The Problems page · What counts as a problem · When you get a notification · Privacy

Turning notifications off

Notifications are on by default, and every one of them can be turned off. Open Settings → General → Notifications. Changes are saved at once.

To stop…	Do this
all notifications, for good	Untick Show desktop notifications about new problems in connected clusters. Nothing is watched for notifications any more; the Problems page still works.
all notifications for an hour	Press Mute for 1 hour: in Settings → General → Notifications, under Recent notifications on the Problems page, or on a notification itself where your system shows its buttons. Unmute ends it early.
one kind of problem	Under Notify about, untick the category: Nodes, Pods, Workloads, Jobs, Volume claims, Certificates, Flux, Argo CD or Gateway API. Security and Credentials are the other way round: off until you tick them.
one cluster (a noisy development cluster)	Under Clusters, untick it. A cluster turned off here never notifies.
notifications from Sextant at the system level	Use your system's notification settings (Windows: Settings → System → Notifications; macOS: System Settings → Notifications; Linux: your desktop's notification settings or do-not-disturb). Sextant uses the system's notification service, so the system's do-not-disturb applies too.

During Mute for 1 hour, what would have been shown is still listed under Recent notifications on the Problems page (marked "muted"), so you can catch up later. A category or cluster turned off, or notifications turned off altogether, is not watched for notifications at all, so nothing is recorded for it; its problems are still on the Problems page.

Notifications only ever cover clusters you have connected in this run of Sextant. A cluster you never open sends nothing, and Sextant never connects a cluster just to watch it. The one exception is the opt-in Credentials category: it comes from your kubeconfig file, not from the cluster, so it covers every cluster of your kubeconfig sources (except clusters you turned off) without connecting any.

The settings are kept in settings.json under notifications (see Settings).

The Problems page

Open Cluster → Problems in the sections tree (or type problems in the command palette). It lists the problems of the open cluster:

• grouped by category (nodes, pods, workloads, jobs, volume claims, certificates, Flux, Argo CD, Gateway API, Warning events) and then by namespace; each row has the reason, the message, how long ago it began, and a link to the object's details;
• filtered by the namespace selector at the top, like any table;
• Security findings turns on the Security category (off by default): Baseline Pod Security violations of workloads, see Security posture; it is the same setting as Security under Notify about;
• Only new since… hides what began before your mark; Mark all as seen moves the mark to now (the first visit sets it);
• Recent notifications below: the last 100 notifications of every cluster, including those muted for the hour and those folded into a summary, with Mute for 1 hour and Clear.

The Cluster section header shows a red counter: the problems of the open cluster that would notify (see below), so a pending pod or a single restart does not keep it lit.

On a very large cluster the page keeps at most 2000 objects with problems per kind and says so when it has to drop older ones.

What counts as a problem

Category	Problems	Notifies
Nodes	Not ready; memory, disk or PID pressure; network unavailable	yes
Pods	CrashLoopBackOff, image pull errors, container config errors, OOM kills	yes
	A recent restart (15 minutes), pending (with the scheduler's reason), running but not ready, failed	screen only
Workloads	Deployments, Stateful Sets and Daemon Sets with replicas unavailable (not while a rollout is progressing normally), a rollout past its progress deadline or without progress for 10 minutes	yes
Jobs	Failed	yes
Volume claims	Lost	yes
	Pending	screen only
Certificates (cert-manager)	Not ready (not while being issued), issuance failed, expiring (within 14 days by default: Settings → General → Notifications → Warn this many days before a certificate expires), expired. TLS Secrets without cert-manager are not checked in the background: see [[cert-manager and certificates	cert-manager-and-certificates]]
Flux	Sources, Kustomizations and Helm Releases that are not ready (not while reconciling or waiting for a dependency)	yes
Argo CD	Applications that are degraded or whose sync failed	yes
Gateway API	Gateways, listeners and routes with a problem, as the [[Gateway API	Gateway-API]] section explains it
Security (off by default)	Workloads and Pods that violate the Baseline Pod Security Standard; see [[Security posture	Security-posture]]
Credentials (off by default)	Kubeconfig credentials (a client certificate, a JWT or OIDC token) that expire within the warning days (Settings → Clusters → Kubeconfig → Warn about credentials expiring within (days), 14 by default) or have expired, read from the kubeconfig without connecting; also for clusters that are not connected. See [[Kubeconfig management	Kubeconfig-management]]
Warning events	Every Warning event	screen only

States that often heal by themselves count only after a short grace (2 to 5 minutes), so a pod that is pending for a few seconds is not a problem. Cert-manager, Flux, Argo CD and Gateway API are watched only when the cluster has them.

When you get a notification

• Only new problems. When a cluster connects (or Sextant starts, or you turn a category on), the problems already there are noted quietly; only problems that begin afterwards notify. They show also while the window is hidden in the tray.
• Once per state. A crash-looping Deployment is one notification, not one per pod or restart; a failing CronJob is one, not one per run. The same state is not told again unless it went away for 30 minutes and came back.
• Grouped and limited. Problems that start within a few seconds of each other come as up to three notifications, or as one summary ("5 new problems in prod"); at most six notifications a minute, the rest wait. A problem that went away while waiting is not told.
• Click a notification to bring Sextant forward and open the object (a summary opens the Problems page). If the cluster was disconnected meanwhile, Sextant opens that cluster instead.

Privacy

Notifications are shown by your operating system's notification service. Nothing is sent anywhere else: no server, no telemetry. Text that comes from the cluster (a condition message, an object name) is shortened and cannot carry formatting or links, because some Linux notification services would otherwise interpret it.

Next: Settings, Using Sextant.