What’s Changed in groundcover’s Autonomous Infrastructure for Cutting Kubernetes Costs and Preventing Incidents?

\n

Software Infra: Between the Cloud Bill and OOMKilled, Who Really Knows How Much Capacity You Need?

Kubernetes operations always involve an uncomfortable trade-off. Set CPU and memory requests generously, and your service may seem relatively safe—but resources it never actually uses still get reserved on nodes. Before long, you need more nodes, and waste that was hard to see starts piling up on your cloud bill.

Set requests too low, on the other hand, and things may look more cost-efficient. But when traffic surges, CPU throttling, Pending Pods, memory pressure, and the dreaded OOMKilled can follow.

The problem is that no single configuration can solve this balancing act.

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

This YAML may look reasonable at deployment time. But real-world environments are constantly changing. User traffic fluctuates throughout the day, batch jobs can pile up at certain times, and new feature releases can change an application’s resource-consumption patterns. There’s no guarantee that what was right a few weeks ago is still right today.

In Kubernetes, requests are more than just numbers. They are the basis on which the kube-scheduler decides which node to place a Pod on, and they affect both cluster bin-packing efficiency and decisions about scaling out the nodes. Requests that are too high reserve capacity regardless of actual usage. Requests that are too low, by contrast, can increase the risk of performance degradation and instability when resources are contested.

As a result, many platform teams find themselves stuck in a cycle of repetitive work:

• Check actual CPU and memory usage.
• Find overprovisioned Deployments.
• Review peak traffic and incident history.
• Update the requests in the YAML.
• After deployment, monitor latency, throttling, and OOM events again.
• Repeat the process when traffic changes.

Even when observability is automated, the final configuration change is often still left to a person. And while this work matters, it’s easy for other priorities to push it aside. It often takes a sharp increase in the cloud bill or an outage for teams to ask, “Were this service’s requests too high—or too low?”

The groundcover Autonomous Infrastructure beta, announced on November 3, 2026, takes aim at exactly this problem. This Software Infra technology uses real telemetry from Kubernetes workloads in operation to continuously evaluate CPU and memory requests, then adjust them within the bounds allowed by policy.

The point isn’t simply, “Usage is low, so let’s reduce it.” Teams also need to consider how lowering or raising requests for a particular workload will affect other Pods on the same node and the spare capacity across the cluster. To keep cost optimization from coming at the expense of reliability, resource configuration becomes a loop of observe → decide → make a bounded change → audit and roll back.

That leaves one question:

Will operators no longer have to adjust every Kubernetes request by hand?

Not yet. Workloads where misjudging peak demand could be dangerous—such as databases, message brokers, and services with strong seasonality—still need to be handled conservatively. But the shift toward treating repetitive, measurable resource-tuning work as a target for automation is unmistakable.

groundcover’s beta signals that observability is moving beyond showing “what happened” and beginning to take the next step: helping determine “what should actually change,” within safe boundaries.

From Software Infrastructure Observability to Adjustment: The Autonomous Operations Loop Enabled by eBPF Telemetry

How would an operator’s role change if a dashboard did more than simply show “what happened”—if it could actually change Kubernetes configurations?

Traditional Kubernetes operations are largely reactive. Operators check dashboards for CPU utilization, memory usage, Pod restarts, OOMKilled events, and latency. When they spot a problem, they investigate the cause, modify requests or limits in YAML, and deploy the changes. Between observation and action lie human judgment, tickets, approvals, and deployment procedures.

groundcover’s Autonomous Infrastructure aims to change this workflow. Using production telemetry powered by eBPF, it continuously observes how workloads actually behave and can adjust Kubernetes CPU and memory requests within defined policy boundaries. In other words, observability expands beyond analysis into a control loop with a clearly defined scope.

Observe
  ↓
Analyze resource usage and risk
  ↓
Validate policies and thresholds
  ↓
Adjust Kubernetes requests
  ↓
Reobserve performance, cost, and reliability outcomes

The key here is not “automated changes” in themselves. It is the closed-loop control system in which telemetry informs the next operational decision, and the results of that decision are validated through telemetry in turn.

Why eBPF Telemetry Matters

Kubernetes resource right-sizing cannot be based on average CPU utilization alone. Average CPU usage may be low even as sharp peaks occur at certain times, while a sudden spike in memory usage can lead to an OOM kill. Changes to a single Pod’s configuration can also affect the placement stability of other workloads running on the same node.

groundcover uses application and infrastructure telemetry collected by its existing eBPF sensors. Because eBPF can observe execution flows and system events at the kernel level, it is well suited to revealing how containers and processes actually behave without requiring code instrumentation.

This gives Software Infra operations teams a broader picture than simple “utilization”:

• Actual CPU and memory usage patterns across containers and processes
• Resource pressure signals such as CPU throttling, memory pressure, and OOMKilled events
• Resource relationships among workloads running on the same node
• The impact of request changes on node packing and scheduling
• The waste caused by over-reservation and the reliability risks of under-reservation

Crucially, this does not require building a new data pipeline from scratch. Environments already using a supported groundcover sensor can begin making right-sizing decisions based on telemetry they have already collected. The approach aims to reduce the duplication of first collecting data for observability, then building up another long-term dataset for automation.

From “Recommendations” to “Bounded Adjustments”

Many existing optimization tools offer recommendations such as, “Reduce this Deployment’s CPU request from 500m to 250m.” But for a recommendation to become an actual change, an operator has to review it, edit the manifest, deploy it, and then check for side effects. At scale, this process can easily fall behind.

Autonomous Infrastructure narrows this gap within policies defined by the user. For example, an operator might set boundaries like these:

- Targets: development namespaces or specific stateless Deployments
- Minimum CPU request: 100m
- Maximum CPU request: 1,000m
- Minimum memory request: 256Mi
- Maximum memory request: 2Gi
- Increases to requests: require user approval
- Limits: excluded from automatic changes

The system then considers actual telemetry alongside node and cluster conditions to recommend or make adjustments that lower overprovisioned requests or raise requests where there is a risk of insufficient resources. The key is to assess not just an individual container, but also how a change could affect overall node headroom and Pod placement.

Conservative Automation That Only Adjusts Requests

In its beta phase, groundcover targets requests for automation—not limits. This distinction matters greatly in Kubernetes operations.

requests are the reserved resources that kube-scheduler uses when placing Pods. If a request is much larger than what a workload actually needs, nodes may be underutilized and the cluster may keep more nodes than necessary. On the other hand, if a request is too small, resource contention can increase the likelihood of degraded performance or scheduling problems.

By contrast, limits are more directly involved in setting the maximum resources a container can use while running.

• Lowering a CPU limit can increase CPU throttling and worsen response times.
• Lowering a memory limit can put the application at risk of being OOMKilled.

That is why this technology first focuses on adjusting requests to improve scheduling and reservation efficiency. If a recommended request exceeds a user-configured limit, the system does not force the change; it flags the situation for review. This design puts runtime stability ahead of the speed of automation.

Operators Aren’t Disappearing—They’re Becoming Policy Designers

Introducing autonomous operations does not make SREs or platform engineers unnecessary. Instead, their focus shifts from repeatedly editing values to designing policies, boundaries, and acceptable levels of risk.

The questions operators need to answer become even more important:

• Which namespaces and workloads should be eligible for automatic adjustment?
• What should the minimum and maximum bounds be for CPU and memory requests?
• Should increases to requests be applied automatically, or should they require approval?
• Which services should prioritize latency and availability over cost savings?
• Should databases, message brokers, and batch systems be excluded?
• What SLO degradation after a change should trigger an immediate rollback?

As a result, the Software Infra operating model changes:

Before:
Check dashboards → Investigate the problem → Edit YAML → Deploy → Verify afterward

Autonomous operations:
Design policies → Adjust based on telemetry → Review audit logs → Validate SLOs → Improve policies

This is more than simple automation. It is the convergence of observability, FinOps, and Kubernetes platform engineering into a single operational loop. Cost savings are only one outcome. The more fundamental value lies in continuously balancing resource reservations and reliability based on real-world operational data.

Software Infra: Why Change Only Requests? Designing Brakes for “Autonomy”

What happens if automation mistakenly lowers a memory limit? The application may fail to get the memory it needs and be OOMKilled immediately. If it lowers a CPU limit too far, a surge in traffic can increase CPU throttling and drive up response latency.

That’s why the groundcover Autonomous Infrastructure beta doesn’t automatically change every Kubernetes resource setting. Its key safety mechanism is, counterintuitively, what it doesn’t change: it leaves limits untouched.

Requests and limits play different roles in Kubernetes

Kubernetes requests and limits may look similar, but they serve different purposes in production.

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

• Requests: The reservation used to determine which node a Pod can be placed on. The kube-scheduler compares a node’s remaining allocatable resources with the Pod’s requests to decide whether the Pod can be scheduled.
• Limits: The maximum resources a container can use while running. Exceeding a CPU limit can cause throttling, while exceeding a memory limit can lead to an OOM kill.

In other words, requests are more closely tied to cluster resource reservations and placement efficiency, while limits are more closely tied to the application’s ability to stay alive at runtime.

Adjusting requests improves cost and scheduling

Excessively high requests reserve node resources regardless of actual usage. For example, consider a service that uses only 100m of CPU and 200Mi of memory but has the following configuration:

resources:
  requests:
    cpu: "1"
    memory: "2Gi"

Regardless of its low utilization, this Pod tells the scheduler it needs one CPU core and 2Gi of memory. This can lead to wasted resources in several ways:

• There’s less room to schedule new Pods.
• The cluster autoscaler may add nodes unnecessarily.
• Node bin-packing becomes less efficient.
• Actual cloud infrastructure costs increase.

groundcover uses production telemetry to identify this kind of over-reservation and reduce requests. Conversely, when it detects signals such as higher actual usage, CPU throttling, or memory pressure, it aims to increase requests to improve scheduling stability.

This isn’t just a cost-saving feature. From a Software Infra perspective, requests are control values that jointly determine deployability, node density, autoscaling behavior, and resource contention between workloads.

Why not automatically change limits?

When a limit is changed incorrectly, the impact is much more direct.

| Automatic change | Expected benefit | Risk of an incorrect adjustment | |---|---|---| | CPU request | Optimized resource reservations, improved node density | Less scheduling headroom during peak periods | | Memory request | Improved placement efficiency, detection of under-reservation | Increased risk of node memory pressure | | CPU limit | Adjusted runtime ceiling | More throttling and worse latency | | Memory limit | Adjusted runtime ceiling | Immediate risk of being OOMKilled |

Memory usage, in particular, is harder to predict than CPU usage. It can spike in a short time due to cache growth, JVM heap changes, large requests, batch jobs, or memory leaks. If a memory limit is lowered based on historical observations and a peak goes undetected, the service can terminate without warning.

CPU limits aren’t necessarily safe to automate either. They won’t immediately terminate a process like memory limits can, but lowering them can increase CFS throttling. As a result, p95 and p99 latency can worsen, leading to more API timeouts and retries.

So the beta follows a clear principle:

Optimize reservations using telemetry, but leave runtime ceilings under operator control.

What if the recommended request exceeds the limit?

Even when analysis indicates that a request should be increased, the recommended value may exceed the current limit. Applying that request as-is can undermine the meaning of the Kubernetes resource configuration and require an operational decision to change the limit itself.

Rather than forcibly changing these workloads, groundcover marks them as Bounded. In other words, the system signals: “This workload appears to need more reserved resources, but doing so would exceed the safety boundary set by the operator.”

This doesn’t mean the automation has failed. It means the automation recognizes the limits of its authority—and stops. In critical production environments, that kind of brake can be more valuable than autonomy.

“Autonomy” doesn’t mean unlimited authority

Autonomous Infrastructure is designed less as fully automated operations and more as closed-loop control within clearly defined boundaries.

Observe telemetry
→ Analyze over- and under-reservation
→ Check policies and minimum/maximum values
→ Adjust requests only
→ Validate changes in SLOs, OOMs, throttling, and cost

Operators can define the scope at the namespace, Deployment, or cluster level, and set minimum and maximum values for CPU and memory requests. They can require user approval for request increases, and changes to policies are recorded along with audit logs.

Instead of making the risky promise that “the system changes everything for you,” this approach automates only the repetitive, high-impact work of reserving Kubernetes resources. Ultimately, what matters in this Software Infra technology isn’t the scope of its automatic changes—it’s the fact that it’s designed to know where automation should stop.

Software Infrastructure Autonomy: What to Check Before Savings—Benefits and Blind Spots

If a clear figure such as “30% average cost savings” had been published, the decision would be easy. But what has been disclosed so far about the groundcover Autonomous Infrastructure beta is its capabilities and measurement framework. There are not yet any broadly applicable figures for average savings or incident reduction, or independently verified results from large-scale deployments.

So the first question to ask when evaluating adoption should not be “How much will we save?” but:

Can we improve resource reservation efficiency in our clusters while maintaining our SLOs and stability?

Separate “potential savings” from “actual spend”

Potential savings shown on a dashboard are an important starting point, but they do not automatically mean a lower cloud bill. Lowering requests reduces the resources Kubernetes needs to reserve and can improve Pod packing efficiency. But for costs to actually fall, that change must eventually lead to fewer nodes, smaller node instances, or scale-downs by the autoscaler.

For example, even if CPU requests are reduced by 30%, costs may stay the same if:

• The change does not free up enough capacity to reduce the node count
• Another resource—such as memory, ephemeral storage, or the Pod limit—is the bottleneck
• Nodes cannot be removed because of minimum node counts or reserved-instance contracts
• Headroom needs to be maintained intentionally in preparation for traffic peaks

Software Infrastructure teams should therefore measure savings across three layers:

| Measurement layer | Question to ask | Key metrics | |---|---|---| | Reservation efficiency | Has unnecessary resource reservation decreased? | Requested CPU and memory relative to allocatable capacity | | Infrastructure efficiency | Can the same workload run on fewer nodes? | Node count, utilization per node, bin-packing efficiency | | Financial impact | Has actual spend gone down? | Cloud bill, instance costs, cost per unit of traffic |

In other words, “we reduced requests” is only the beginning of success. The ultimate test is whether the actual infrastructure cost structure changed without degrading performance.

Evaluating autonomy on cost alone is risky

Kubernetes resource requests are not just a cost setting. They affect scheduler placement decisions, resource contention between Pods, QoS, and cluster autoscaler behavior. So even if automatic request tuning helps reduce costs, it could still negatively affect service stability.

When evaluating success, be sure to track these operational metrics alongside cost:

• p95 and p99 latency: Do response times worsen during peak periods after requests are lowered?
• CPU throttling rate: Does increased CPU contention cause processing delays?
• OOMKilled and memory pressure events: Has memory headroom become too tight?
• Pending Pod duration: Has resource placement become more difficult?
• Restart count and error rate: Is any loss of stability leading to application errors?
• Rollback frequency: Are the automated changes reliable enough for day-to-day operations?

The more costs are reduced, the more resource headroom is likely to shrink. Average usage may look fine during normal operations, while batch jobs or traffic spikes can trigger higher latency and throttling all at once.

The biggest blind spot: “Past data doesn’t guarantee future peaks”

eBPF-based production telemetry provides richer evidence than static settings or a limited set of metrics. But even the best observational data is still based on past patterns.

Low usage over the past week does not mean traffic will also be low during next month’s peak. Workloads like these, in particular, call for a conservative approach to automated right-sizing:

• Reconciliation and batch jobs that run only at month- or quarter-end
• Services with event-driven traffic, such as campaigns, concerts, or ticket launches
• Services that rely on unpredictable external APIs
• JVM-based applications with rapidly fluctuating memory usage
• Stateful workloads such as databases, message brokers, and search engines
• Critical APIs where a sudden traffic spike can immediately affect the customer experience

In these environments, peak usage, peak duration, and recovery time matter more than average usage. Autonomy policies should reflect the following priorities, rather than pursuing a single savings target:

Critical service stability → SLOs → Performance headroom → Cost optimization

“Requests only” is a safeguard, but it does not mean “risk-free”

There’s a clear reason the groundcover beta automatically adjusts only requests, not limits. Lowering a memory limit can immediately increase the risk of OOMKilled events, while lowering a CPU limit can worsen latency through throttling.

That said, changing only requests does not eliminate operational impact. Lowering requests can allow more Pods to be placed on a node, increasing actual resource contention on that node. Conversely, raising requests can improve stability, but it may leave Pods Pending or prompt the cluster autoscaler to add nodes, increasing costs.

That’s why the key to autonomy isn’t “making changes automatically” in itself. It’s having a controllable change loop like this:

Analyze telemetry
→ Set policy scope and minimum/maximum values
→ Apply to a limited set of workloads
→ Validate changes in SLOs, errors, and costs
→ Keep, adjust, or roll back

A practical measure of success: “Safe repeatability,” not savings

If the first goal in evaluating this technology is “How much did we cut costs this month?”, it can lead to over-optimization. A more realistic measure is whether you’ve built a safely repeatable operational automation loop.

For an initial rollout, it’s best to start with a development or staging namespace and stateless services. You can then consider expanding to production once the following conditions are met:

• Automated changes cause no significant deterioration in latency or error budgets
• OOMKilled events, CPU throttling, and Pending Pods do not increase
• Change history and policy scope can be tracked through audit logs
• Previous request values can be restored quickly when needed
• Estimated savings are tied to changes in actual node operating costs or cloud bills

Ultimately, the value of Software Infrastructure autonomy isn’t captured by a single impressive savings figure. It depends on whether telemetry leads to configuration changes, whether those changes are validated against SLOs and cost metrics, and whether they can be rolled back in a controlled way when problems arise. At this stage, the best way to use Autonomous Infrastructure is not to view it only as a “cost-saving tool,” but to evaluate it as a control loop that automates safe Kubernetes operational decisions.

Software Infrastructure Automation: From Small Experiments to Operational Standards

“How much will we save if we turn it on?” is an important question. But when adopting autonomous infrastructure, there’s another question we should ask first:

If something goes wrong, how quickly will we notice—and how safely can we roll it back?

Technology like groundcover Autonomous Infrastructure, which adjusts Kubernetes requests based on real telemetry, can reduce both costs and operational burden when applied well. But that doesn’t mean automation should be applied to every workload right away. Successful software infrastructure automation isn’t achieved the moment you turn on a feature; it’s built by gradually expanding the scope in ways you can verify.

The first goal of automation isn’t savings—it’s recoverability

During the initial rollout, you need to be able to answer the following operational questions before focusing on “estimated monthly savings”:

• Which Deployment and namespace received the changed requests?
• How did CPU throttling, OOMKilled events, and latency change before and after?
• If an SLO degrades, who will stop the automation, and according to what criteria?
• How quickly can you restore a healthy state after reverting the policy to a previous version?
• Could automated changes conflict with the cluster autoscaler, HPA, or existing deployment pipelines?

The risk of autonomy isn’t simply that a single request value might change. Requests can have cascading effects on scheduling, node bin-packing, Pod QoS, and autoscaling conditions. So before expanding automation into an operational standard, you need to track cost and reliability metrics together on the same dashboard.

Observation-only phase: establish a baseline without automated changes

In the first phase, don’t enable automatic application. Instead, observe the over- and under-allocation candidates suggested by groundcover. The goal isn’t to trust the tool’s recommendations at face value, but to compare them against your organization’s actual traffic patterns and verify that the suggested values make sense.

It’s a good idea to review the following data over at least one full business cycle:

| Validation item | Why it matters | |---|---| | Actual CPU and memory usage versus requests | To check peak usage and variability—not just average utilization | | CPU throttling rate | To determine whether lowering CPU requests affects performance | | OOMKilled events and memory pressure | To check that memory recommendations don’t introduce reliability risks | | p95 and p99 latency | To detect user impact that average response times may not reveal | | Pending Pod duration | To determine whether increased requests create scheduling bottlenecks | | Node count and requested resources relative to allocatable capacity | To assess whether estimated savings could actually reduce the number of nodes | | Actual cloud bill | To compare calculated savings with real changes in cost |

Be sure to include atypical load patterns, such as month-end batch jobs, weekend traffic, major events, and regular data processing. Lower usage over the past few days alone isn’t enough reason to reduce requests: the next traffic peak could bring unexpected throttling or Pod restarts.

Validate changes in a limited namespace

Once you’ve gathered enough observational data, move to a development or staging namespace. From there, expand to stateless internal services with limited failure impact.

Good initial candidates include:

• Horizontally scalable API servers
• Asynchronous workers that can retry
• Internal management tools
• Services in development and test environments
• Stateless applications with relatively stable traffic patterns

There are also workloads that are best left out of the initial automation rollout:

• Databases and caches
• Message brokers
• Storage and StatefulSet-based systems
• ML inference services with rapidly changing memory usage
• Critical services where a single failure could affect the entire business
• Applications with highly event-driven or seasonal traffic

At this stage, set clear thresholds for your automation policies. For example, define a minimum CPU request so it can’t be reduced too far, and set a memory request floor that accounts for historical peak usage with sufficient headroom. An approach like groundcover’s beta design—keeping limits in place while adjusting only requests—is especially useful in these early experiments. It lets you improve scheduler reservation efficiency without changing runtime ceilings.

Build approvals, rollbacks, and audits into the operational workflow

As automation expands, the more important question isn’t “Who approves changes?” but “Under what conditions can changes be approved automatically?” Having people review every change can erode the benefits of automation, but applying every change unconditionally can leave you without control.

A practical operating model is to set policies according to the risk of each change:

Low risk: Apply request decreases automatically
Medium risk: Apply request increases after approval
High risk: For critical namespaces and stateful workloads, provide recommendations only

For example, decreasing requests can deliver significant cost optimization, but an overly aggressive reduction could eliminate headroom for peak conditions. Conversely, increasing requests may improve reliability, but it can reduce available node capacity and lead to Pending Pods or additional node scaling. It’s therefore advisable to use different approval policies for increases and decreases.

The following items should also be built into operational procedures:

• Version control for policies before and after changes
• A history of automation by workload
• Audit logs showing who made each change and when
• Criteria for stopping automation if SLOs degrade
• A fast rollback procedure to restore previous request values
• Correlation analysis across deployment events, HPA behavior, and cluster autoscaler events

The key isn’t the automated change itself. It’s whether you can trace the cause and roll it back when something goes wrong.

Cost savings count as a win only after SLOs are met

From a software infrastructure perspective, resource right-sizing is both a FinOps initiative and a reliability initiative. Even if you reduce the number of nodes and improve request efficiency, the savings aren’t a success if p99 latency worsens or OOMKilled events increase.

It’s safest to decide whether to expand automation in the following order of priority:

Service stability
→ SLOs and user experience
→ Ability to respond to incidents
→ Resource efficiency
→ Cost savings

This becomes clearer when translated into operational metrics. Before and after applying automation, compare not only costs but also the rate of error budget burn, latency, throttling, OOM events, Pending Pod duration, and rollback frequency. If savings are substantial but rollbacks are repeated or alerts increase, the policy isn’t ready to become a production standard.

Checklist for expanding to an operational standard

Expand the scope of automation gradually, and only when the following conditions are met:

• [ ] At least one peak traffic period or batch cycle has been observed.
• [ ] After automated changes, p95 and p99 latency and the error rate remain within acceptable limits.
• [ ] CPU throttling, OOMKilled events, and memory pressure have not increased.
• [ ] Change history and policy versions can be audited.
• [ ] The person responsible has actually tested the rollback procedure.
• [ ] Different approval criteria apply to request increases and decreases.
• [ ] Databases, brokers, and critical stateful workloads are managed under separate policies.
• [ ] Estimated savings have been validated against actual changes in node count or cloud costs.

Autonomous infrastructure isn’t an operating model you can perfect all at once. It becomes an operational standard only after you start with observation, validate changes in a limited environment, and repeatedly test recovery procedures. In the end, good automation isn’t the automation that makes the most changes. It’s automation that makes the changes you need safely—and can be brought under control immediately when something goes wrong.