AIOps for Kubernetes · Runs in your cluster

The AI agent that runs Kubernetes day two

Live cluster topology, alert noise collapsed to real issues, and an agent that can exec into a pod, find the fault and propose the fix. Self-hosted, and it changes nothing without your say-so.

Self-hosted in your cluster · Zero telemetry · Reads freely, writes on approval · Free forever tier

What is AIOps for Kubernetes?

AI for Kubernetes operations, or AIOps for Kubernetes, uses an autonomous agent for day-two cluster work: live topology, cluster health, alert de-noising, anomaly detection, and Kubernetes troubleshooting to a root cause with auto remediation on approval. NudgeBee runs inside your own cluster, reads freely, and gates every change behind human approval.

Live, de-noised, in your cluster
Live mapEvery workload, pod, node and namespace is tracked with version-aware updates, so the topology reflects the cluster as it is now, not a nightly snapshot.
One issueCrash loops, image-pull backoffs, OOM kills and restarts collapse to a single issue per owning workload, instead of one alert per pod per restart.
In your clusterThe agent dials out over one WebSocket. No inbound ports, no exposed API server, no VPN.
A live service map for a Kubernetes cluster, showing workloads and the real dependency edges between them, with a failing service traced to its root cause.

A cluster map that is always current

NudgeBee maps the entire Kubernetes estate live into its own store: workloads, pods, nodes and namespaces, with resource-version-aware updates and reliable removal of things that no longer exist.

Node hardware, capacity and placement are read directly, including spot-versus-on-demand detection across Karpenter, EKS, AKS, GKE and Spotinst.

One issue per workload, not one alert per pod

Owner-level de-duplication collapses the usual flood into something a human can act on, instead of one alert per pod per restart.

  • Crash loops, image-pull backoffs, job failures, CPU throttling and pod-not-ready all group under the workload that owns them.
  • OOM detection triggers at 92% container and 95% node memory.
  • Around 70 named alert types auto-escalate based on how long they have persisted.
  • Every issue gets a 0 to 100 score covering severity, whether it is production, duplicate history, SLO impact, restart count and config changes, mapping to P0 at 80, P1 at 60, P2 at 40.
NudgeBee Issues view grouping 193 raw Kubernetes events into four ranked issues per workload, each with a P1, P2 or P3 severity, an event count and a triage score.
An in-browser terminal execing into a running Kubernetes pod, with Terminal, Logs, Metrics and Traces tabs, and the session recorded for audit under prod RBAC.

Exec, logs, metrics and traces, without leaving the page

The agent works the cluster the way you would, from the browser, running only read-only diagnostics.

  • An in-browser terminal execs straight into a pod, with a debugger and profiler alongside it.
  • Prometheus queries auto-tune their resolution to the time range you are looking at.
  • It runs the same read-only diagnostics you would: kubectl, helm, argocd and PromQL.
  • Log and trace queries run against your existing backends, in place.

It flags the metric that moved before it pages you

Three swappable engines run across CPU, memory, latency, error rate and replica count, with heavy false-positive suppression so a single quiet weekend does not trigger a page.

  • IsolationForest, the default, at 1% contamination with 100 estimators.
  • DBSCAN, density-based detection for per-metric outliers.
  • Z-score, classic statistical detection at 3 sigma.
An anomaly detection chart for the orders-svc memory working set, with the IsolationForest engine flagging a rise above the normal baseline band at 12:40, before any alert fired.
An eight-step Kubernetes cluster upgrade planner moving from v1.28 to v1.29, with pre-flight checks running and three deprecated APIs found that block the apply until they are migrated.

Upgrade planning that checks before it moves

An eight-step upgrade planner checks before it moves, and executes only what it declared.

  • Cross-references a live registry of deprecated APIs.
  • Checks Helm chart compatibility before the upgrade.
  • Runs a health diff before and after the change.
  • Execution uses an allowlisted set of kubectl and cloud CLI commands, so the plan cannot wander outside what it declared.

CIS, CVEs and misconfigurations, on a schedule

NudgeBee orchestrates scanners as jobs inside your cluster, and findings land in the same ranked queue as everything else, not a separate console.

Scanners run on a schedule:
  • kube-bench (CIS)
  • Trivy CIS
  • Trivy image CVEs
  • Popeye
  • Certificate expiry
  • Version skew
  • Unused volumes
A Kubernetes security scan queue on cluster prod-us-east-1, with Trivy, kube-bench, Popeye and certificate findings ranked by severity from Critical to Medium against specific workloads.

It reads freely. It changes nothing without you.

Two modes, drawn at the tool layer, not left to the model's judgement.

Reads

Diagnoses without asking

Read-only diagnostics run without asking, so finding the fault in a cluster is never slowed by a prompt.

Writes

Gated behind your approval

Every create, update and delete is classified at the tool layer and gated behind explicit human approval.

No self-granted access

The agent is forbidden from modifying RBAC to grant itself access it lacks.

It does the work, not you

It never asks you to go and run commands yourself.

Untrusted by default

All tool output is treated as untrusted input, a deliberate prompt-injection defence.

Approvals arrive where the team already works:
  • Slack
  • Microsoft Teams
  • Google Chat
  • Signed link

It works with your observability, it does not replace it

NudgeBee queries your existing backends in place, in their own native query languages. Metrics, logs and traces are not shipped out to a third party.

Queried in place, in native dialects including PromQL, LogQL, KQL, NRQL and Elasticsearch DSL.

Browse all 78 integrations

Runs in your cluster. Nothing leaves.

Self-hosted

Runs inside your own Kubernetes cluster.

Zero telemetry

Nothing phones home.

Outbound only

The in-cluster agent dials out over a single WebSocket. No inbound ports, no exposed Kubernetes API server, no VPN.

Encrypted and signed

Credentials encrypted at rest with AES-256-GCM. Agent messages signed with Ed25519.

Bring your own model

Nine provider routes across AWS Bedrock, OpenAI, Azure OpenAI, Google AI, Vertex AI, SageMaker, HuggingFace and Anthropic. Embeddings can run on-device.

Readable source

Read the implementation, with a free Community edition.

Kubernetes FAQ

Frequently asked questions

For the engineer who lives in kubectl and distrusts magic.

Book a Demo
AI for Kubernetes operations means using an autonomous agent to run day-two cluster work: mapping live topology, collapsing duplicate alerts into real issues, detecting anomalies, and investigating failures to a root cause. It runs inside your own cluster, reads through your existing tools, and gates every change behind human approval.
A dashboard shows you graphs and leaves the work to you. This agent reads the same signals, collapses alert noise into one issue per workload, execs into pods to investigate, and proposes a fix. It acts on the cluster, with your approval, rather than only visualising what is already broken.
Only with your approval. Read-only diagnostics run freely, but every create, update or delete is classified at the tool layer and gated behind explicit human approval. Auto-Pilot is available for scheduled rightsizing, with dry-run and guardrails, but nothing changes outside what you have configured and approved.
No. NudgeBee queries your existing observability backends in place, in their native query languages such as PromQL and LogQL, and auto-tunes Prometheus resolution to the time range. It layers on top of the stack you already run rather than replacing it or asking you to re-instrument.
Owner-level de-duplication collapses crash loops, image-pull backoffs, OOM kills, job failures and restarts into a single issue per owning workload, instead of one alert per pod per restart. Each issue gets a 0 to 100 score, and around 70 alert types auto-escalate based on how long they persist.
Yes. An in-browser terminal execs straight into a pod through the outbound in-cluster agent, with a pod debugger and profiler alongside it. The agent runs the same read-only diagnostics you would, kubectl, helm, argocd and PromQL, with no inbound ports and no exposed API server.
Kubernetes metric anomalies are detected by three swappable engines: IsolationForest with 1% contamination and 100 estimators as the default, DBSCAN, and Z-score at 3 sigma. They run across CPU, memory, latency, error rate and replica count, with heavy false-positive suppression so a quiet weekend does not page anyone.
Yes. An eight-step upgrade planner cross-references a live registry of deprecated APIs, checks Helm chart compatibility, and runs a health diff before and after the change. Execution is limited to an allowlisted set of kubectl and cloud CLI commands, so the plan cannot wander outside what it declared.
Yes. The full implementation is readable: the agent architecture, the prompts and the quality gates. You can self-host it in your own cluster and run it in production internally for free, on a free Community edition covering up to two clusters or cloud accounts.
There is a free forever tier covering up to two clusters, with no credit card required. Kubernetes operations is part of the platform every paid plan includes, alongside the other assistants, and paid plans are detailed on the pricing page. You can validate it against your own clusters first.

One platform, one knowledge graph. Add another assistant with no new install and no re-integration.

Free forever · No credit card

Point it at your own cluster.

Free forever on up to 2 clusters. No credit card. Self-hosted, so nothing leaves your environment.

Read the source on GitHub