Skip to main content
When the cluster has a Prometheus, its alerting rules say what’s wrong: a pod crash-looping, a volume filling up, a node not ready. Alerts lists the alerts it’s firing and those pending, worst first. Open it from the sidebar under Cluster, below Events, with G then Z, or by typing “alerts” into ⌘K. Lumovi reads them from the Prometheus the Metrics page uses, through the cluster’s API server as you, and again every 30 seconds while the page is open. Without one, the page says “Lumovi found no Prometheus in this cluster.”, with Metrics source… to choose one. A line above the list names the source, like “From prometheus-operated in monitoring, the Metrics page’s source · 42 alerting rules”.

The list

Each row is one alert: one instance of a rule, so two pods crash-looping are two rows.
Prometheus's alerts, firing and pending, with one opened beside the list: what it says, since when, and its runbook.Prometheus's alerts, firing and pending, with one opened beside the list: what it says, since when, and its runbook.

Alerts, firing and pending, with one opened beside the list.

Critical comes first, then Warning, Info and None; within each, firing before pending, then the one that began first. Click a column’s header to sort by it instead. An alert of severity None, like Watchdog, fires all the time on purpose, to show the alerting works. It’s listed, but never counted as firing. With nothing else firing, the page says “No alerts are firing. 38 alerting rules are quiet.”, how many of severity none it left out, and Show None to list them. The chips above the list filter by severity, and by firing or pending; the filter (/) matches an alert’s name, its summary and its labels’ values. The header’s namespaces filter it too: an alert whose labels name one of them, or every alert when all are shown.

One alert

Click a row to open it beside the list, as an object opens:
  • Summary and Description, as its rule writes them.
  • Object: what it’s about, with a link.
  • Labels: every one.
  • Rule: how long it waits pending before it fires, or “Fires at once”; its group; and the value that set it off.
  • Runbook, where its rule gives one: a link named by its host and the last part of its address, like “runbooks.prometheus-operator.dev › kubepodcrashlooping”, the whole address in its tooltip. A rule’s runbook is whatever its author wrote, so where it goes is said before you open it. Lumovi opens only https:// links (and http://localhost); any other is shown as text, to copy.
An alert that stops firing while it’s open says “This alert isn’t firing or pending any more.” Nothing on the page changes anything: it only reads what Prometheus holds.

On the overview

The overview’s Warnings tile counts warning events in the last hour. Where alerts fire under the namespaces shown, it says how many too, like “3 alerts firing”, as a link to the Alerts page, and takes the color of the worst of them. Alerts of severity none aren’t counted there either.

Who sees what

Prometheus doesn’t know about namespaces’ RBAC. Whoever may reach it through the cluster (get on services/proxy where it runs) sees every alert it holds, from every namespace, with their labels and annotations. The header’s namespaces only narrow what’s shown. See Who can read what it collects.
Reaching it needs the same permission the Metrics page does: see Permissions. Without it, the page says “Lumovi couldn’t read Prometheus’s alerts:”, with why and Try again.

Events

What happened in the cluster, newest first or on a timeline.

Usage history

The Prometheus Lumovi reads, and how it finds it.