Alerts

A guide to getting notified when something breaks

KubeGlance can watch your clusters and notify you when something needs attention — a pod crash-looping, a node going away, a rollout finishing. This page explains how to set alerts up and, importantly, what to expect on each device.

Turning alerts on

On Mac, open KubeGlance ▸ Settings ▸ Alerts (or click the menu-bar icon and choose Alerts & Settings…). On iPhone and iPad, open the Settings tab and tap Alerts. Flip Enable Alerts, and allow notifications when prompted. If you dismissed the prompt, the screen shows an Open Settings button that takes you straight to the system notification settings.

Pick a starting point

The quickest way to start is a preset:

• Critical only — crashes, restart storms, and nodes going NotReady. The default.
• Critical + availability — adds degraded workloads, pods stuck Pending, stalled rollouts, and failed jobs.
• Everything, incl. rollouts — also tells you when rollouts start and finish, jobs complete, and nodes are added or removed.

A preset is just a set of rules you can then tune — nothing is locked.

Rules and where they apply

Each alert is a rule: a signal to watch, where to watch it, and how loud it should be. Tap a rule to edit it, or add your own. You can scope any rule to:

• Clusters — any cluster, or only those you've colored (for example, only your red “production” clusters).
• Namespaces — all, everything except the system namespaces, or one specific namespace.
• A specific name — so you can say “tell me when this job completes” without hearing about every other job.

The signals you can watch include: pods crashing or failing, restart storms, pods stuck Pending or Terminating; nodes going NotReady, being added or removed, or crossing a CPU/memory threshold; workloads becoming degraded; rollouts that start, finish, or stall; and jobs that fail or complete.

How loud each alert is

Every rule has a severity, which controls how the notification behaves:

• Critical — time-sensitive: it can break through a Focus or Do Not Disturb, with your permission.
• Warning — a normal banner with sound.
• Info — silent; it just appears in your notification list. Good for “rollout finished” and other good-news events.

You can also ask a rule to notify you again when the problem clears (a quiet “recovered” follow-up).

What to expect: Mac vs. iPhone & iPad

This is the important part, and we'd rather be honest than oversell it.

On Mac, KubeGlance stays running (it can tuck into the menu bar), so it watches your clusters continuously and notifies you within seconds. This is real-time.

On iPhone and iPad, Apple doesn't let apps keep watching a server in the background. KubeGlance checks whenever iOS grants it a moment — which can be minutes to hours apart, and not at all while the app is force-quit or in Low Power Mode — plus every time you open the app. So on-device iOS alerts are a helpful nudge, not a replacement for a pager. If you need guaranteed, immediate paging on your phone, that requires a small always-on component next to your cluster; that option is on our roadmap.

Battery

Checks are lightweight and skip themselves in Low Power Mode. On iPhone and iPad the system already limits how often background work runs, so the battery cost is minimal by design.

Privacy

Alerts are evaluated entirely on your device against your own clusters. Nothing about your cluster is sent to us — the same guarantee as the rest of KubeGlance.

Not getting notifications?

• Check that notifications are allowed for KubeGlance in System Settings (Mac) or Settings ▸ Notifications (iPhone/iPad).
• Make sure the rule you expect is enabled, and its scope actually matches the cluster and namespace in question.
• On iPhone/iPad, remember checks are opportunistic — open the app to force an immediate re-check.
• Alerts fire on changes: a pod that was already failing when you enabled the rule won't re-alert until it recovers and fails again.

Contact

Questions or ideas for signals we should add? hello@kubeglance.com