The question we get asked most often before someone connects their first cluster is: what will NudgeBee actually do to my cluster? The short answer is: in the first hour, nothing at all. NudgeBee reads. It does not write.
This article walks through what actually happens when you connect a cluster, what NudgeBee reads during that initial discovery period, and what a first triage result looks like. No invented CLI output, no fabricated dashboard screenshots. Just a clear description of the process so you know what to expect before you start.
What NudgeBee Reads
NudgeBee connects to your cluster using a service account you create. That service account has read permissions only. The permissions cover the resources NudgeBee needs to understand cluster state: pods, nodes, events, deployments, replicasets, daemonsets, statefulsets, services, endpoints, horizontalpodautoscalers, and resource quotas.
NudgeBee does not request write permissions during setup, and it does not use write permissions during normal operation. The only moment a write permission becomes relevant is when you explicitly approve a fix proposal, at which point the approved action is applied using a separate, scoped action rather than via the read-only service account. Until you approve something, nothing changes in your cluster.
What NudgeBee does not read: your application secrets, ConfigMap contents, PersistentVolume data, container logs by default, or anything outside the Kubernetes API. It reads object metadata and status fields, not your application data.
The Initial Discovery Period
When you first connect a cluster, NudgeBee spends the first several minutes doing a full read of current cluster state. It is building a baseline picture: what workloads exist, what their resource requests and limits are, what their current status is, and what recent events look like.
During this period, you will not see any alert triage results. NudgeBee needs enough context to distinguish a normal cluster condition from an anomaly. A pod that has been in Pending state for thirty seconds looks different from one that has been Pending for twenty minutes. Without the baseline, those two conditions are indistinguishable.
The discovery period is also when NudgeBee reads your existing namespace and workload label structure. If you have team labels on your workloads, those are used to populate ownership information in the triage results. If you do not, the ownership field will show the namespace name, which is usually enough context to route a finding to the right person.
NudgeBee never runs kubectl apply on its own. Every fix proposal waits for your explicit approval before anything changes in your cluster.
First Triage Results: What the Output Looks Like
Once the discovery period completes, NudgeBee starts correlating events and workload state into triage findings. The first results you see will reflect whatever is actually happening in your cluster at that moment, which means if your cluster is healthy, you may not see any findings immediately.
A triage finding has a few consistent components. The workload identifier: which deployment, daemonset, or statefulset is implicated, along with its namespace and cluster. The event pattern: what sequence of Kubernetes events was observed that led to this finding. The proposed explanation: a plain-English description of the most likely root cause based on the event pattern. And the proposed action: a specific remediation step, if one is applicable.
For example, if NudgeBee observes a deployment where pods are repeatedly entering CrashLoopBackOff, preceded by OOMKilling events on the node, the finding would name the specific deployment, show the event sequence, identify memory limit exhaustion as the likely cause, and propose a specific resource limit increase for your review.
You review the proposal. If it looks right, you approve it. NudgeBee applies the change. If it does not look right, you dismiss it or modify the approach. NudgeBee never applies a change without that approval step, regardless of how confident the root cause diagnosis is.
Cost Findings in the First Hour
Cost findings require a bit more time than event-based findings, because NudgeBee needs to observe a workload's resource utilization over time to distinguish an idle workload from one that is idle right now but actively used throughout the day.
Within the first hour, you may see cost findings for workloads that show obvious idle signals: zero CPU utilization combined with zero recent events suggesting active use. These are typically staging or development deployments that were left running after a test or demo.
More nuanced cost findings, like workloads whose resource requests are significantly higher than their actual utilization, require a longer observation window before NudgeBee has enough confidence to surface them. You will see those findings accumulate over the first day or two rather than immediately.
What to Check Before Connecting a Production Cluster
For most teams, connecting a staging or development cluster first is a good approach. Not because production is unsafe, but because a lower-stakes environment lets you see what NudgeBee finds and develop a sense of which findings are relevant to your setup before adding a production cluster.
A few things worth verifying before connecting any cluster:
- Check your alert volume. If your cluster currently generates many alerts per day, NudgeBee will have more source material to work with and will start producing triage findings faster. If your cluster is very quiet, the first hour may not surface much.
-
Review your namespace ownership labels. If your namespaces have consistent
teamlabels, triage findings will include routing context. If they do not, that is fine, but adding them before connecting will make the initial output more immediately actionable. - Confirm your Slack or PagerDuty integration if you want notifications. The Team tier ($149/month) includes Slack and PagerDuty integration. Connecting these before your first cluster means findings will appear in your existing alert workflow immediately, rather than requiring you to check the NudgeBee dashboard separately.
What NudgeBee Does Not Cover
This is worth being explicit about. NudgeBee is focused on alert triage and workload-level cost attribution. It is not a general-purpose observability platform. It does not replace Prometheus, Grafana, or your existing log aggregation.
NudgeBee does not analyze container logs by default (log-based signals require additional configuration). It does not provide network-level observability. It does not manage cluster configuration beyond the specific remediation proposals you approve. It does not handle infrastructure provisioning or node scaling.
The scope is intentionally narrow: take the alert storm, find the responsible workload, propose the fix, wait for your approval. That scope means the setup is correspondingly simple. There are no agents to install on nodes, no instrumentation libraries to add to your applications, and no changes to your existing monitoring pipeline. NudgeBee reads what Kubernetes already exposes.
If your expectation going into the first hour is "NudgeBee will immediately replace my on-call workflow," that expectation needs adjusting. If your expectation is "NudgeBee will start building a picture of my cluster's event patterns and give me a more focused starting point when an alert storm happens," that is accurate.