Observability Has Spent 20 Years Finding Problems. It's Time to Start Fixing Them.

For the better part of two decades, the observability industry has been helping engineers answer the same question: what's wrong with my infrastructure?

We've gotten remarkably good at answering it. We can collect billions of events, reconstruct distributed transactions, correlate metrics with logs, and now use AI to investigate incidents in seconds. The amount of information available to engineers today would have been unimaginable ten years ago.

And yet, after all that investment, the outcome is often the same. An engineer gets an alert, opens a dashboard, figures out what needs to change, and goes off to change it.

I've been thinking about how absurd that is.

We built increasingly sophisticated systems to understand our infrastructure, but we still rely on people to manually act on much of what those systems discover. The industry has treated understanding the problem as the finish line, when it should have been the starting point.

I think that's about to change.

The Kubernetes problem everyone knows about

Take something as basic as allocating CPU and memory in Kubernetes.

When an engineer deploys an application, they have to decide how much of each resource it needs. The problem is that they're making this decision before they know how the application will behave in production. Even with good historical data, they're estimating future demand.

Most teams compensate by over-provisioning. It's the rational thing to do. Nobody wants to be responsible for a production incident because they tried to save a few dollars on compute.

But that safety margin has a cost. Kubernetes schedules workloads based on their resource requests, so over-provisioning can leave expensive capacity sitting unused. Across hundreds of nodes and thousands of workloads, those small inefficiencies add up.

Under-provisioning creates a different set of problems. Insufficient CPU requests can leave workloads competing for resources, while insufficient memory requests can increase the risk of eviction under node pressure. And when actual memory consumption exceeds a container's limit, the result can be an out-of-memory kill.

What makes this particularly frustrating is that we already have the information needed to make better decisions.

An observability platform can see actual resource consumption, identify usage patterns, and distinguish workloads that consistently need more capacity from those that have been allocated far too much.

So why does an engineer still need to review that information and manually update resource requests?

And why should they have to keep doing it as application behavior changes?

The problem isn't that we lack the data. It's that we've built an artificial boundary between observing infrastructure and operating it.

Why we acquired Wand

In September, groundcover acquired Wand, a company focused on autonomous Kubernetes resource optimization.

The acquisition was driven by a fairly simple idea: if we already understand how infrastructure behaves in production, we should be able to use that understanding to continuously improve how it operates.

Wand had built technology to optimize Kubernetes resource allocation. groundcover already had an eBPF-based observability platform collecting detailed production telemetry across applications and infrastructure.

Putting the two together gives us something neither approach delivers as effectively on its own: a direct connection between understanding how infrastructure behaves and taking action to improve it.

Today, we're introducing the first result of that combination, groundcover Autonomous Infrastructure, available in beta.

It continuously optimizes Kubernetes CPU and memory requests based on actual workload behavior. When resources are over-provisioned, it can reduce unnecessary allocation. When workloads need more resources, it can increase requests within defined boundaries.

Importantly, these decisions aren't made in isolation. The system considers how workloads fit onto nodes, how much capacity remains available, and whether an adjustment could create resource pressure elsewhere.

Because optimizing infrastructure isn't just about reducing cost. It's about finding the right balance between efficiency and reliability, and continuously maintaining that balance as conditions change.

The advantage of already being there

There's another reason this combination is interesting, and it comes down to architecture.

Most Kubernetes optimization products need to install their own components, collect workload data, and build enough history before they can make meaningful recommendations.

For groundcover customers, that information already exists.

Our eBPF sensor is already running in their Kubernetes environments, collecting the production telemetry needed to understand resource consumption. The data is already stored in their own cloud, through our BYOC architecture.

That changes the experience considerably.

When a customer opens Autonomous Infrastructure, they can immediately see which workloads are over-provisioned, which are running short of resources, and what their estimated savings could be. They can evaluate the opportunity before allowing the system to make a single change.

There's no additional agent to deploy and no separate observability dataset to build.

This is an important distinction. We aren't introducing another disconnected infrastructure tool that needs to learn about your environment. We're extending the observability platform that's already there.

And while we're calling it autonomous, that doesn't mean we're asking engineers to surrender control.

The system is off by default. Customers decide which workloads, namespaces, or clusters to optimize, and define the boundaries within which changes can happen. Policy changes are tracked, and during the beta, optimization is limited to CPU and memory requests rather than resource limits.

Autonomy should remove repetitive operational work, not remove engineers from decisions that matter.

From understanding infrastructure to operating it

I believe we're approaching a fundamental shift in what an observability platform is supposed to be.

The first generation of monitoring tools told us when something was broken. The next generation helped us understand why. More recently, AI has made it possible to investigate complex production problems without requiring engineers to manually search through every signal.

Each step has reduced the amount of work required to understand what's happening.

But understanding isn't the same as solving.

If a system can reliably identify an inefficient resource allocation, determine a better configuration, and make that change within clearly defined safety boundaries, what value is there in requiring an engineer to perform those steps manually?

The answer, increasingly, is none.

That doesn't mean every infrastructure decision should be automated. Production environments are complicated, and there will always be situations that require human judgment. But a surprising amount of infrastructure management consists of repeatable decisions based on information we already collect.

Those decisions are good candidates for autonomy.

Kubernetes resource optimization is where we're starting because it offers a clear way to measure the results. We can quantify wasted resources, identify stability risks, and evaluate the impact of adjustments over time.

But the larger opportunity is to make observability an active part of infrastructure operations rather than a separate system that reports on them.

This is also how I think about the future of groundcover. Our investment in eBPF, BYOC, and AI-driven investigations has been about giving engineers complete access to what's happening in their environments, without forcing them to compromise on data, cost, or control.

Autonomous Infrastructure builds on that foundation. It turns information we're already collecting into improvements the platform can make on its own, under the customer's direction.

Our beta is available now to every groundcover customer running our Kubernetes sensor, at no additional cost. We're also working with design partners to shape what comes next.

For years, observability vendors have competed to show engineers more information, faster.

I think the next competition will be about how much work that information can eliminate.

The future of observability isn't another dashboard telling you what to fix. It's infrastructure that knows how to improve itself.