Diagnose¶
KubeManta's triage surface — free rule-based cascade and health views plus a Pro AI Diagnosis sub-tab and scheduled AI SRE reports.
Tier: Free — some features Pro
What it does¶
Diagnose is KubeManta's triage surface. The Diagnose tab itself is Free — its rule-based views need no license and no LLM key. Only the AI Diagnosis sub-tab, and the scheduled reports built on it, are Pro.
The free, rule-based side covers two sub-tabs. The Pod Failure Visualizer is a
leveled dependency graph — root cause, blocked, and indirectly affected —
useful for outages that span multiple resources, where it isn't obvious which
failure caused which. The dependency edges come from a naming convention you
already use: an init container called wait-for-<something> is read as this pod
waiting on that one, so a pod held open by a failure elsewhere is placed
downstream of it rather than listed as another independent casualty. A pod that
is failing with nothing naming it as a dependent still appears — one level in,
as a victim with no identified blocker. Selecting a node in it opens a detail drawer whose
Relationships section shows the owner chain from Pod up through ReplicaSet to
Deployment, which Services select a workload, and PVC status and binds. Health
surfaces rule-based health signals per namespace or resource, with no AI
involved.
The Pro side, gated on the ai feature and requiring your own LLM key, adds
AI Diagnosis: a namespace scan that sweeps a namespace for unhealthy pods and
returns an AI-prioritized, explained summary, and a focused AI pod analysis
that gives a root-cause explanation for a single failing pod using its logs,
recent events, phase, and restart count. The last namespace diagnosis is stored
and restored — badged CACHED — when you reopen that namespace, but running it
again always calls the LLM; pod analysis is never stored. The AI sub-tabs
respect the platform's AI Guardrails — data residency, cost caps, and the
master AI on/off switch all apply. With the master AI switch off the AI
Diagnosis sub-tab is not shown at all; with AI on but the account unlicensed it
shows an Upgrade to Pro card. Either way the rule-based views keep working
unaffected.
The Reports sub-tab, also Pro, configures recurring AI-generated cluster health reports. You pick a schedule and namespaces — a filterable multi-select of discovered namespaces — and a background scheduler gathers the same read-only namespace state the AI diagnosis path uses and runs one guardrail-enforced summarization pass. Schedules are real wall-clock schedules — daily, weekly on a weekday, or monthly on a day, at a chosen time, plus cron and a legacy every-N-hours mode — all timezone-aware, and a restart never double-fires a slot. Reports are stored with age-based pruning, viewable in-app, exportable as a formatted PDF with real headings, lists, tables, and code blocks rather than raw markdown, and can be delivered through any channel enabled under Alerts → Integrations, with one failing channel never blocking the others. Every report rides the same guardrails as any other AI call — data residency, cost caps, prompt audit, and redaction.
Quick Fix and root-cause runbooks¶
Quick Fix sits on the cascade and incident surfaces and is deliberately narrow. KubeManta classifies a pod's failure, matches it against a small catalogue of root-cause templates, and — when a template can derive a safe change — registers a plan you review and approve. Nothing is applied by matching a template.
There are exactly three templates, and only one of them can produce a change:
| Template | Matches | What you get |
|---|---|---|
| OOMKilled — raise memory limit | Container OOMKilled (exit 137) | A rendered patch raising the memory limit, planned for your approval — but only when the container already has a memory limit to raise and its owner is a Deployment, StatefulSet, DaemonSet, or ReplicaSet; otherwise advice to set one |
| Pending — unschedulable | Pod Pending / FailedScheduling / Insufficient cpu|memory | Advice only — no manifest |
| CrashLoopBackOff — config/image | CrashLoopBackOff (config / image / probe) | Advice only — no manifest |
The two advisory templates return no manifest on purpose: no safe, specific patch is derivable from a crash signature or a scheduling failure alone, and the alternative — a blind restart — is the kind of "remediation" that hides a problem rather than fixing it.
Anything that matches no template falls through to the AI path (Pro), which is where open-ended diagnosis lives. So Quick Fix is not a general remediation engine, and should not be planned around as one; it is a fast path for the three failures common enough to be worth encoding.
Recommending is Free and admin-only, and mutates nothing. Applying is separate and Pro — it goes through the same approval-gated change pipeline as any other write, with the full audit trail.
Setup¶
Reach Diagnose from the sidebar's OPERATE group, or open an incident from Overview and use its Diagnose action. The Run AI Diagnosis action on a Workloads row is a different entry point: it opens the AI Copilot on that resource rather than the Diagnose view. Use the Pod Failure Visualizer when one failure appears to be causing several others; select a node to see a workload's owner chain, Services, and PVCs; run an AI namespace scan to triage everything at once; and drill into a single pod for AI pod analysis. Pod analysis reads the pod's logs, so the Analyze button stays disabled until you have streamed them.
Troubleshooting¶
The two AI switches fail differently, so the symptom tells you which to check.
An Upgrade to Pro card in place of a working scan means the licence is missing
the ai entitlement. No AI Diagnosis sub-tab in the tab bar at all means the
master AI on/off switch under Admin → AI Guardrails is off — on a single pod
that same switch shows an "AI features are disabled by your administrator"
notice. In both cases the rule-based views remaining functional is the
confirmation that the rest of the product is healthy. If a namespace diagnosis
looks stale — badged CACHED, describing state that has since changed — it is
the stored result of the last run, restored when you opened the namespace; run
it again for a fresh answer. If a scheduled report never fires, confirm the
schedule's timezone and that at least one delivery channel under Alerts → Integrations is actually enabled — a report with no
working channel still generates and stores, but has nowhere to be delivered.
Generated from KubeManta 1.2.0 — this page is rendered from the product's own documentation, so it cannot drift from what ships. Manifest built 2026-09-12T02:14:45Z.