Three steps from alert noise to resolved incident
NudgeBee intercepts every Kubernetes alert, traces root cause across workloads and metrics, then delivers a single actionable fix. Your team approves or rejects, nothing runs automatically.
Triage: every alert, one converging view
NudgeBee connects to your Prometheus, Grafana, Datadog, or New Relic instance over a read-only API key. Incoming alerts are enriched with workload context and deduplicated before any analysis begins.
Alert fires
Prometheus AlertManager or your observability platform fires an alert over webhook or API.
Deduplicate and enrich
NudgeBee suppresses duplicates, pulls workload labels, namespace, resource limits, and recent deployment history.
Context assembled
Pod logs (last 500 lines), CPU and memory trends, and cluster events are gathered into a single context window for AI analysis.
Incoming alert payload (example)
alertname: KubePodCrashLooping
namespace: production
pod: api-gateway-7d9f4b-xk2rp
severity: critical
fired_at: 2026-07-14T09:43:17Z
annotations:
summary: Pod restarted 8 times in 10 minutesDiagnose: root cause, not surface symptoms
The AI engine cross-references pod logs, metrics anomalies, cluster events, and recent config changes to identify what actually caused the alert, not just what it says on the label.
What the AI engine correlates
-
Pod logs (last 500 lines)
Stack traces, OOM messages, and connection refused errors pinpoint what failed first.
-
Metrics over the prior 30 minutes
CPU throttle, memory pressure, and request latency trends show whether resource starvation preceded the crash.
-
Cluster events and recent deploys
ConfigMap changes, image tag bumps, and pod eviction events are correlated by timestamp.
-
Upstream service dependencies
If a database or sidecar is also degraded, NudgeBee notes the dependency chain so the fix targets the real source.
Diagnosis output (example)
Root cause: OOMKill on api-gateway
Memory limit 256Mi, peak usage 312Mi over last 18 min
Correlated: image bump v2.4.1 -> v2.4.2 22 min before first OOM
Suggested fix: raise resources.limits.memory to 512Mi on api-gateway Deployment
Approve: one decision, then you are done
NudgeBee delivers a single notification to your Slack channel or PagerDuty. It includes the diagnosis, the proposed change, and two buttons. You decide. Nothing happens until you do.
NudgeBee
Alert
KubePodCrashLooping in production/api-gateway
Root cause
OOMKill: memory limit 256Mi exceeded (peak 312Mi) after image bump v2.4.2
Proposed fix
resources:
limits:
memory: 512Mi
What happens on each path
You approve
NudgeBee applies the YAML patch via kubectl. A confirmation message arrives in the same thread 30 seconds later with the new pod status.
You reject
Nothing changes on the cluster. NudgeBee logs the rejection and you can route the alert to a runbook or escalate manually. Cluster stays exactly as-is.
No response (timeout)
After your configured timeout (default 15 minutes), NudgeBee escalates to the next on-call in your rotation. Nothing runs automatically.
What NudgeBee can and cannot change
NudgeBee operates within a strictly scoped permission boundary. You define what it may propose; it never acts outside that list.
In scope (configurable)
- Deployment resource limits (memory, CPU)
- Replica count adjustments
- Rolling restart of a single workload
- ConfigMap value patches (whitelisted keys only)
- HPA min/max replica bounds
Out of scope (never touched)
- Secrets and credentials
- Namespace or cluster-level RBAC
- Image registry or tag changes
- Network policy modifications
- Anything not in your approved-actions list
See it work on your own cluster.
Connect your first Kubernetes cluster in under 10 minutes. Solo plan is free, no card needed.