monitoring namespace as a Flux HelmRelease. The Monitoring panel is a live read of the stack: release state, deployed versions, every ServiceMonitor Prometheus scrapes, and the optional hardware exporters.
Install state and versions
The status reports the release identity and both version signals:
Alongside it, the
helmRelease block carries the Ready condition with reason and message — see the status model. The panel also shows the deployed configuration the release was installed with, and the desired configuration the form would apply next:
Re-applying with the same values is a no-op reconcile; changing storage or retention triggers a Helm upgrade with the new values.
ServiceMonitors
The status lists everyServiceMonitor on the supervisor — the objects that tell Prometheus what to scrape — with namespace, labels, and endpoint count. A typical supervisor’s inventory spans well beyond the stack’s own namespace:
Some of these are created by their own operators (CDI, KubeVirt, Rook); the rest are platform-managed: Celum applies a known set covering Cilium, Hubble, the cluster agent, Ceph, and the hardware exporters. The install form lets you select which platform-managed ServiceMonitors to enable — an empty selection means the full default set. A re-apply ServiceMonitors action recreates the entire platform-managed set at any time; it is idempotent and safe to run after an operator upgrade removed one.
Opt-in exporters
Hardware and probe exporters are not part of the default install — each is a separate chart you enable per supervisor:
The status reports each exporter’s installed state, so the panel doubles as the inventory of what this supervisor actually collects. Install only what the hardware justifies — the GPU exporter on a GPU-less supervisor is a DaemonSet doing nothing.
Exposed routes
When the supervisor runs a shared Gateway, the stack’s UIs are published on it — the status lists the routes with hostname, address, and TLS state, e.g.grafana.<domain>, prometheus.<domain>, and loki.<domain> behind a single shared-gateway address. See Gateways & Routes for how the shared Gateway works.
When the release is not ready
The most common monitoring failure is simply an unready HelmRelease — and the panel surfaces the chart controller’s reason and message directly:1
Read the condition
The panel footer shows the
Ready condition. InstallFailed / UpgradeFailed reasons come with the exact Helm error — a values problem, a timeout, an immutable-field conflict.2
Check version drift
lastAttemptedRevision newer than revision means an upgrade is failing while the old version keeps running — fix the reported error, then re-apply.3
Recover from a stuck rollback
If Helm is wedged mid-rollback, the panel’s recover action resets the release state so the next reconcile can proceed.
A
Ready release with missing metrics is a different failure class: check that the relevant ServiceMonitor exists (re-apply the set), and that the target’s namespace lets Prometheus reach it.Permissions
Related
Platform health overview
The status model every panel shares.
Logs
Loki and Alloy — installed into the same
monitoring namespace.Infrastructure & nodes
The node capacity and hardware the exporters report on.
Gateways & Routes
The shared Gateway that publishes Grafana and Prometheus.