Live thinking panel
Watch the agent’s reasoning, tool calls, and investigation events stream in as they happen — not a spinner, the actual chain of thought.
Open source · Fleet-wide AIOps for Kubernetes
Kubernaut detects signals, investigates root causes with an LLM-powered agent, selects a remediation workflow, and executes the fix — on a single cluster or across your entire fleet — or escalates to a human with a full RCA when it can’t.
Root cause found and a fix selected in under 3 minutes on average, while humans stay in control through approval gates and audit trails.
How it works
Six phases, one Remediation Orchestrator, and full audit trails from the first signal to the final notification.
Every remediation starts one of two ways: autonomously, the moment a signal fires from AlertManager or a Kubernetes Event, or interactively, when an operator opens a live investigation, watches it unfold in real time, and decides whether the recommended fix runs — more on that below. Either way, it’s the same pipeline from here.
A dedicated controller enriches the signal with Kubernetes context (owner chain, namespace labels), then classifies environment, priority, and severity via Rego policy.
The Kubernaut Agent investigates with 36 built-in tools — or, for a fleet-managed cluster, the byte-identical tool schema served by that cluster’s K8s MCP Server — produces a root cause analysis, and selects a workflow from the RemediationWorkflow catalog.
Low-risk actions auto-approve via OPA/Rego policy and confidence thresholds; higher-risk remediations notify an operator via Slack, Teams, or PagerDuty.
Fixes run as Kubernetes Jobs, Tekton Pipelines, or Ansible (AWX/AAP) — each under a dedicated ServiceAccount with short-lived, no-standing-privilege tokens.
Post-remediation verification confirms alert resolution, checks for spec drift, and produces a four-dimensional health score.
Multi-channel delivery to Slack, PagerDuty, Teams, or log/file, with circuit-breaker retry and a full audit trail per attempt.
Analysis and fix selection are the fast part — about 3 minutes on average across the incidents below. Most of what’s left is deliberate: a 5-minute stabilization window before Effectiveness even starts scoring, so Kubernaut isn’t judging a cluster that hasn’t settled yet. End to end, signal to a verified fix, typically completes in under 12 minutes — no human required in the loop, for the cases that don’t need one.
Kubernaut Console
Every investigation is also a live conversation. The same agent that runs autonomously the moment a signal fires is reachable directly, too — open the Console over MCP or A2A, start a fresh investigation or join one already running, and watch it think in real time, with the same approval gates.
Recorded live: the Console investigating a real KubePodCrashLooping incident, discovering a workflow, and ruling out an in-cluster patch because the cluster is GitOps-managed. Loops like this typically close end to end — including Kubernaut’s own built-in wait before it verifies the fix — in under 12 minutes.
Watch the agent’s reasoning, tool calls, and investigation events stream in as they happen — not a spinner, the actual chain of thought.
Root cause arrives as a structured card: causal chain, confidence score, severity, and tool call count.
Review the recommended remediation workflow and its parameters, with a countdown confirmation before anything runs.
Approve, decline, or escalate with a reason — directly from the same conversation, no context switch to a separate tool.
Real incidents
No cherry-picked screenshots — every signal, root cause, and outcome below is captured verbatim from a real incident run.
Every request in the namespace returning 403
An Istio AuthorizationPolicy with an empty deny rule is silently blocking every request in the namespace.
Corrected the AuthorizationPolicy scope, restoring traffic without touching the app.
All three etcd members at ~99.97% fragmentation
Compaction had run but defragmentation never had — leaving ~62 MiB of dead BoltDB pages across all three etcd members, live data down to 16 KiB.
Sequential etcdctl defrag across all three members — followers first, then leader — with health checks between each.
web-frontend crash-looping after an ArgoCD sync
A bad commit synced by ArgoCD’s self-heal loop keeps re-breaking the ConfigMap — patching the cluster directly would be undone within seconds.
Selected a git-revert workflow instead of an in-cluster patch, so the fix survives the next sync.
predict_linear projects this PVC exhausting in under an hour
A sidecar container was writing ~400 MiB/hour of uncompressed data into a 512Mi PVC with no retention policy — caught by trend prediction before the volume filled.
Expanded the PVC online via its CSI driver, buying time before PostgreSQL would have crashed, while the underlying write-rate and retention issue gets fixed separately.
api-gateway crash-looping — but the alert fired in the wrong namespace
A bad directive in the postgres-config ConfigMap, two namespaces away, crashed Postgres — which cascaded into api-gateway and payment-processor, both crash-looping on a database they couldn’t reach.
Removed the bad directive from the ConfigMap and restarted the affected Deployment, instead of stopping at the symptom in the alerting namespace.
The etcd operator’s CSV vanished entirely — OLM couldn’t resolve the package
The etcd Subscription was patched to reference a CatalogSource that no longer existed, leaving OLM unable to resolve the operator — its ClusterServiceVersion was completely absent from the namespace.
Deleted and recreated the Subscription CRD against the correct CatalogSource, restoring the operator’s CSV.
Real signals, root-cause analyses, and outcomes captured verbatim from Kubernaut’s open demo scenario suite. The remediation workflows shown are reference examples — every deployment authors its own workflow catalog so fixes match your organization’s SOPs, tooling, and change-management process.
Fleet Management
At hundreds of clusters, provisioning is already solved — your GitOps or fleet control plane handles that well. What doesn’t scale on its own is operations: every cluster still means its own on-call triage, its own root-cause digging, its own runbook sprawl. Fleet Management plugs into the estate you already run and extends one Kubernaut deployment across every cluster, so incident response scales with your fleet instead of your headcount.
Security, by construction
Every guarantee below holds even if the model gets something wrong — no standing credentials, no unbounded blast radius, no action without an audit trail.
The agent that investigates is read-only everywhere it runs — a locked-down investigator role with no write access, ever. What it can even be pointed at is gated separately: only resources labeled Kubernaut-managed are ever admitted, checked at the ingress point before the agent is invoked — two independent gates, not one assumption. The default role ships narrow; granting it anything more is an explicit, separately-bound decision you make — and Kubernaut flags it as a privilege-escalation risk when you do — never a side effect of a normal install or upgrade.
Remediation itself runs as a Kubernetes Job or Tekton PipelineRun on the target cluster, under a ServiceAccount you provision and scope to that one workflow — not a shared, standing credential. That’s different from agents that draft their own remediation and RBAC per incident: whatever grants that RBAC still has to hold every permission it might ever hand out. Kubernaut’s operators define the workflow and its ServiceAccount ahead of time, through the same review as any other change, so the blast radius is fixed and audited before an incident happens — not computed by a model in the middle of one.
Every result from an MCP tool call the agent reads back — Secret data, ConfigMaps, pod details — passes through a credential-scrubbing pipeline covering two dozen-plus patterns for database URLs, API keys, and tokens before it ever reaches the LLM’s context, not just a blanket redaction of Secret objects by type. If that pipeline ever fails, Kubernaut withholds the tool result entirely rather than risk passing anything unsanitized through — the failure mode is losing a data point mid-investigation, not leaking a credential.
A shadow agent — a second, independent model — reviews every tool result for injection attempts, then reviews the full investigation again as it moves into workflow discovery — a phase handled by its own, separately configurable model — to catch attacks spread thin across multiple steps. It’s opt-in and fails closed: anything that looks like it’s steering the investigation rather than informing it stops execution for a human to look, not a guess to run with. Already run a dedicated prompt-injection or LLM-guardrail product? This layers underneath it, not instead of it.
Key capabilities
Every capability below is designed around one rule: humans stay in control, and every action is explainable after the fact.
Autonomous end-to-end remediation, or interactive sessions where operators guide the agent via MCP or A2A — both share the same approval gates and audit trails.
Prometheus alerts (reactive and proactive) and Kubernetes events, deduplicated by fingerprint at the ingress point before entering the pipeline. ServiceNow incidents are on the roadmap as a third signal source.
The Kubernaut Agent uses LLM providers (Vertex AI, OpenAI, Anthropic, Bedrock, Ollama, and more) with native Kubernetes inspection tools.
Searchable, declarative RemediationWorkflow CRDs matched by category and label with confidence scoring.
Kubernetes Jobs, Tekton Pipelines, or Ansible (AWX/AAP) — pick the engine that matches the remediation.
Start in dry-run — Kubernaut investigates and selects a workflow but executes nothing. Layer in human approval next, gated by Rego policy, confidence thresholds, and admission webhooks. Graduate individual workflows to full autonomy only once you trust the results, and roll back at any time.
Full audit trails with 7-year retention, CRD reconstruction from audit events, and operator attribution on every action.
Four-dimensional post-remediation scoring feeds back into the agent, so it learns to avoid repeating failed remediations.
Alert remediation is the pillar live today. Threat Remediation (security signals from Falco, Trivy, OPA/Gatekeeper) and Cost Optimization (FinOps via Koku, Kubecost, and OpenCost) are early-stage proposals under exploration for future releases — see the open issues for where each stands.
Built on tools you already run
Kubernaut plugs into your existing Kubernetes, observability, and automation stack.