Overview¶

The cluster-wide health landing page — an incident list with acknowledgement, incident reports, AI postmortem drafts and response metrics, per-namespace health verdicts, security posture and system health, with an optional embed of your own Grafana dashboard in its place.

Tier: Free

What it does¶

The Overview page is the landing view after login, and it is always cluster-wide: it covers every namespace KubeManta is allowed to see, whatever the top-bar namespace selector is set to. It shows a health verdict per namespace — critical, degraded, healthy or unknown — derived from failing pods, Deployments below their desired replica count, firing alerts, Pending pods and unbound PVCs; an incident list that puts the worst problem first, described below; a one-line verdict for the whole cluster, which also says when alert rules have stopped being evaluated; a system health line with the node-ready count, API server latency and Kubernetes version, refreshed every 60 seconds in the background; and a Security card with the security posture grade and the critical and high counts, which opens the Security tab. The incident list polls every 15 seconds; the namespace grid refreshes when the Server-Sent Events stream signals that a fresh result exists, and falls back to the same 15-second poll when that connection can't be established. /overview is served from a 30-second server-side cache, so a namespace verdict can be up to 30 seconds behind the cluster.

When a Grafana source is configured in Admin → Observability, one of your own dashboards can be embedded as the Overview instead of KubeManta's own cards — useful if you already have a curated cluster dashboard and want it to be the first thing an operator sees on login.

The namespace selector in the top bar scopes Workloads, Diagnose, Terminal and Alerts to one namespace or all tenant namespaces at once; Overview is not among them. What does change this page is the System NS toggle, a button in the Overview header, which shows or hides the namespaces KubeManta treats as system-owned so the page doesn't drown in infrastructure noise by default. Setting it requires an admin, and it applies to everyone. That set is any namespace whose name begins kube-, gke-, gmp-, istio- or knative-, plus these exact names: kube-system, kube-public, kube-node-lease, istio-system, cert-manager, ingress-nginx, monitoring, logging, flux-system, argo, argocd, paas-core and kubemanta-system — plus KubeManta's own release namespace, whatever it is named on your install. Several of those are ordinary names — if you run your own workloads in a namespace called monitoring or logging, it stays hidden from Overview, Workloads and Alerts — and from opening it directly — until System NS is switched on.

Incidents¶

The top of the page is an incident list, not a metric. KubeManta derives a story per unhealthy pod from what it can already see — recent events, the log tail from the CRASHED instance rather than its healthy replacement, the exit code and reason, and the resource picture — and ranks them so the worst is first.

Clicking one opens the full story: what happened, in what order, with the evidence attached. For an admin the same view offers the remediation actions that fit the failure. Restart and Scale execute as soon as you click them, deleting a pod asks for an inline confirmation first, and all three are written to the audit log. The AI-recommended fix is the one that is approval-gated: applying it spends a single-use token issued with the plan, and a high-risk change also makes you type the target's name. A viewer sees the story without the buttons.

This ordering is deliberate. A dashboard that opens on totals asks you to notice the problem yourself; opening on the incidents puts the thing you would have gone looking for at the top of the page.

Incident record and acknowledgement¶

Every incident KubeManta detects is also recorded, so it keeps one identity while it lasts. An incident is identified by its namespace, its workload and the failure reason: when a Deployment's pod is replaced and the replacement fails the same way, that is still the same incident. KubeManta checks the cluster about once a minute in the background, so an incident is recorded and its recovery timestamped whether or not anyone has the Overview open.

The incident dialog shows this record: when the incident was first detected, whether anyone has acknowledged it, and whether the cluster has recovered.

Acknowledge tells your team someone is on it. Anyone signed in may acknowledge, viewers included. It records the time and your name, is written to the audit log, and changes nothing in the cluster. The first acknowledgement stands; acknowledging again does not move it. API keys cannot acknowledge an incident, because time to acknowledge measures a person's response.
Recovered means the cluster reported the workload healthy again: no pod of that workload has any problem KubeManta can see. It does not mean a person confirmed the root cause, and KubeManta never presents it as one. If the cluster cannot be read, or a namespace is hidden by the allowlist, nothing is marked recovered.
A crash-looping pod often switches between symptoms, such as crashing and then running but not Ready. While a workload has an open incident, a lesser symptom is counted as part of it instead of opening a second incident. A failure that comes back within ten minutes of recovering reopens the same incident and is shown as a recurrence.

Incident records are kept for 180 days after recovery, configurable with INCIDENTS_RETENTION_DAYS.

Incident report and postmortem export¶

Show incident report in the incident dialog lays out one timeline of everything KubeManta recorded about the incident, oldest first:

detection, acknowledgement and recovery;
alert firings, and the evidence captured when they fired, including the log tail of the crashed container;
automated AI investigations of the incident;
for administrators: changes made in the incident's namespace (restarts, scaling, applied manifests), Helm operations there, and terminal commands run in that namespace or naming both the namespace and the workload.

The timeline covers 30 minutes either side of the incident. It only includes activity from the incident's own namespace, and you can only open the report for a namespace you are allowed to see. Change history, terminal commands and the text of AI investigations are admin-only everywhere else in KubeManta, so they are only included for an administrator signed in to KubeManta. They are never included when the report is fetched with an API key.

The report also shows two sections alongside the timeline:

Grouped alerts — the alerts that were recorded on this incident without sending a page of their own, each with the reason it was grouped (for example, "both are on node worker-3"). If this incident's own alert was the one grouped, the report says which alert's page covered it. Alerts in namespaces you cannot see are left out entirely. See One page per incident in the Alerts documentation.
Recent changes — writes to the incident's namespace in the 24 hours before it was detected, newest first, each with when it happened relative to detection. Changes to the incident's own workload are marked this workload: that includes its pods and the Helm release that manages it, so an upgrade of a Deployment shows up on an incident about its pods. The sources are the audit trail (restarts, scaling, deletes, applied manifests, approved AI actions — each with a link to its audit event in Activity), Helm operations run through KubeManta, and the release history Helm keeps in the cluster (each revision with a diff against the one before it, for administrators). Who made a change is shown to administrators signed in to KubeManta; other users see the Helm release history, which records no person. Helm release history is included when Expert Mode is on. The section lists what changed and when — it does not score or predict risk. Set INCIDENT_CHANGE_LOOKBACK_HOURS on the agent to change the 24-hour lookback.

Export postmortem (Markdown) downloads the same report as a draft postmortem: a summary table (detected, acknowledged, recovered, and the time each took), the timeline, recent changes, grouped alerts, the captured evidence, and empty Root cause and Action items sections for you to fill in. Secrets are redacted from every log excerpt and free-text field in the export, using the same redaction rules as the rest of KubeManta. The export only includes what KubeManta recorded, so review it before you share it.

AI postmortem draft¶

Administrators on Pro can have AI draft the postmortem. Under AI postmortem draft in the incident dialog, Generate draft sends the incident report to your AI provider in one pass. That is the same report as above, with the full administrator view, including the terminal commands run during the incident. The draft comes back in fixed sections: Summary, Impact, Timeline, Root-cause hypotheses (each with a confidence and the records that support it), What went well, What went poorly, and Action items.

The draft is saved with your AI reports and linked to the incident. The latest one is shown in the incident dialog with Markdown, PDF and HTML downloads, and all of them are listed under Diagnose → Reports. Generate a new draft makes another one and keeps the earlier ones.

What the draft can and cannot tell you:

It knows only what KubeManta recorded: cluster state, alerts, the evidence captured when they fired, changes made through KubeManta, Helm history and commands run in the KubeManta terminal. It has not seen your chat threads, your pager timeline, customer reports, commands run outside KubeManta, or the health of your external dependencies.
Its root causes are hypotheses, not findings. Confirm each one before you act on it or publish it.
The timeline shows what happened close together in time. That does not mean one event caused the next.
People are pseudonymised on purpose. See below.

These points are written into every draft by KubeManta itself, so they are there whatever the AI produced.

People are never named in a draft. Before anything is sent to your AI provider, KubeManta replaces each person in the incident record with a label such as "Operator A" or "Operator B". The label is the same everywhere that person appears in one draft: acknowledging the incident, running terminal commands, making changes, or being mentioned inside someone else's command. Usernames, email addresses and source IP addresses are all replaced. An email address or user flag that doesn't belong to anyone in the record becomes "[person]". KubeManta's own automated actions keep their names, so you can still tell them apart from people.

The draft doesn't store which label belongs to whom. To find out who did something, look up that time in the audit trail (see Activity & Audit), which records the person. This keeps a draft free of personal data once it is exported and pasted into a wiki or ticket, where a data-erasure request could not reach it.

Secrets are redacted from everything sent to the provider, using the same redaction rules as the rest of KubeManta. Log lines and terminal commands are passed to the model as data to analyse, never as instructions to follow. The request goes through the same AI controls as every other AI feature: the AI on/off switch, data residency, cost caps and the egress allowlist. It uses the provider set in Admin → AI.

Only administrators signed in to KubeManta can generate or read a draft, because it contains the terminal record. Viewers do not see drafts in Reports, and API keys cannot generate, list, read or export them. Each draft is written to the audit log. Drafts are kept for as long as other AI reports (AI_REPORT_RETENTION_DAYS, 90 days by default).

Response metrics¶

Below the incident list, Response metrics summarises the last 30 days of incidents in the namespaces you can see. Every figure is measured from when KubeManta first detected each incident:

Incidents: how many were detected, and how many are still open.
Cluster recovered: the share the cluster recovered from, and the median time until it did. As above, this is the cluster's report, not a confirmed root cause, so it is not labelled MTTR.
Time to acknowledge: the median time until someone clicked Acknowledge. Until an incident has been acknowledged the tile says so, rather than showing a number.
First AI hypothesis: the median time from detection, or from the incident's first alert if that came earlier, until an automated AI investigation of it finished with an answer. Incidents with no automated investigation are not counted. Automatic investigation needs an AI provider saved in Admin → AI; without one the tile says that instead of showing a number.

The same figures are available from GET /incidents/response-metrics, which also reports ai_diagnosis_configured.

Setup¶

No configuration is required — Overview works out of the box against any cluster KubeManta can read. The optional Grafana embed is configured under Admin → Observability, alongside the Prometheus and Alertmanager connectors described on the Metrics and Alerts pages.

Troubleshooting¶

If a namespace is missing from Overview, check the namespace allowlist and the System NS toggle — the top-bar selector has no effect on this page. A namespace outside the allowlist, or one whose name KubeManta treats as system-owned, will simply not appear rather than show as unhealthy.

If the namespace grid stops moving while the incident list keeps updating, look at the Server-Sent Events path, but note which direction the dependency runs: the stream carries only a signal that a newer /overview result exists, and that signal is emitted when the result is computed. Reloading the page fetches one directly. A dropped EventSource connection is not the failure it looks like — when the stream is unavailable the page polls /overview itself every 15 seconds.

Generated from KubeManta 1.5.0 — this page is rendered from the product's own documentation, so it cannot drift from what ships. Manifest built 2026-11-03T12:53:14Z.