The News
groundcover announced a significant expansion of its eBPF sensor on at KubeCon + CloudNativeCon NA 2026, adding capabilities that tie application-layer request spans directly to the underlying SQL queries they trigger without requiring SDK instrumentation or changes to existing code. The release extends zero-instrumentation protocol coverage to ClickHouse and SIP, adds Azure OpenAI detection with time-to-first-token metrics for AI workloads, and introduces Kubernetes and cloud context stamping across all telemetry, including data from third-party tools like Fluent Bit and StatsD. The company also announced a Crossplane provider that allows platform teams to manage groundcover configuration as Kubernetes custom resources through standard GitOps workflows, and confirmed GKE Autopilot partner workload status, enabling full eBPF observability in Google’s locked-down managed Kubernetes environment.
Analyst Take
The Instrumentation Tax Is Real, and groundcover Is Betting Against It
Observability has a dirty secret: most of the engineering hours spent on it aren’t spent analyzing production. They’re spent wiring it up. Every new service, every new protocol, every migration to a managed Kubernetes platform means someone has to write instrumentation code, chase down missing labels, or reconcile telemetry that describes the same incident through three different lenses. groundcover’s entire product thesis is that this instrumentation tax is structurally unnecessary, and this release is the most concrete expression of that argument yet.
The SQL correlation capability is the headline feature worth examining closely. When a distributed trace shows a slow request, the next question is almost always whether the database caused it. Today, answering that question typically requires either database-side instrumentation, client library hooks, or both. groundcover’s eBPF sensor intercepts that relationship at the kernel level, surfacing the exact query behind a span without touching application code. For a development organization running dozens of services, that’s not a convenience, it’s a meaningful reduction in mean time to resolution. The ClickHouse addition matters for the same reason: analytics databases running alongside transactional systems are increasingly common in modern stacks, and they’ve historically been instrumentation blind spots.
Context as a First-Class Capability
The Kubernetes and cloud context stamping deserves as much attention as the SQL feature, even if it’s less dramatic. The core problem it targets is label drift: telemetry arrives from multiple sources, each with its own labeling conventions, and the correlation that matters for incident response never happens automatically. By tagging workload, namespace, region, and zone at the point of collection, groundcover shifts context from a post-hoc enrichment problem into a property of the data itself. Extending that context to third-party metrics and Fluent Bit logs is the move that makes consolidation credible. Teams don’t have to rip out their existing instrumentation; they can route it through groundcover and gain the context they’ve been missing.
This architectural choice speaks directly to a dynamic that ECI Research’s Google GovTech Survey Results capture well, though it applies equally to enterprise environments: according to ECI Research, 54.4% of respondents said infrastructure provisioning creates a “moderate bottleneck” where provisioning takes a few days and multiple tickets. Observability tooling that adds to that provisioning surface area compounds the problem. A sensor that self-contextualizes and integrates with existing telemetry pipelines reduces it.
The Managed Kubernetes Question
The GKE Autopilot partnership is strategically significant and easy to underestimate. Managed Kubernetes platforms restrict privileged workloads precisely because privileged access is a security risk. Becoming an approved partner workload means groundcover cleared a meaningful security review and is now available in an environment where most deep observability tools simply can’t run. As platform teams move toward fully managed infrastructure to reduce operational burden, the set of observability tools that can follow them narrows considerably. groundcover is positioning itself to be one of the few that can.
For developers, the Crossplane provider closes a workflow gap. Managing an observability platform through a separate control plane, disconnected from the GitOps workflows that govern the rest of the stack, creates exactly the kind of context-switching that erodes productivity. The ability to define groundcover configuration as Kubernetes custom resources and manage it through the same pull-request workflows as everything else is a small change with a large quality-of-life impact. ECI Research’s Google GovTech Survey Results found that 48.0% of respondents identified “navigating compliance documentation and audit evidence collection” as the greatest source of cognitive load for their developers today. Tooling that integrates into existing workflows rather than demanding new ones directly addresses that burden. Separately, the same survey found that 47.2% of respondents selected “developer velocity and ease of integration” as the factor carrying the greatest weight in their final technical selection process, which is a direct endorsement of groundcover’s zero-instrumentation positioning.
Looking Ahead
groundcover is building toward a world where observability coverage is effectively a property of the cluster rather than a property of each application running in it. The trajectory of this release, SQL correlation, protocol expansion, AI workload detection, context propagation to third-party telemetry, all points toward a platform that can describe the full behavior of a production environment without any cooperation from the application teams running inside it. If that vision holds, the competitive pressure on traditional APM vendors that depend on SDK adoption will intensify. The switching cost for groundcover’s customers goes down as the sensor coverage goes up, because there’s less instrumentation code to maintain and less reason to stay with an incumbent that requires it.
The AI workload detection capability, specifically the Azure OpenAI integration and time-to-first-token metric, is worth watching as a strategic signal rather than a current revenue driver. AI inference is becoming a first-class production workload, and the observability patterns for it are not yet settled. A platform that can observe AI workloads through the same zero-instrumentation model it applies to conventional services is better positioned than one that requires a separate instrumentation approach. Over the next four to six quarters, expect groundcover to deepen this capability, and expect the question of how to observe agentic AI systems running in Kubernetes to become a competitive battleground in its own right.
Stay Ahead of Application Development Trends
Get weekly analyst insights, research notes, event coverage, and AppDevANGLE updates delivered directly to your inbox.
Subscribe for Weekly Insights
Join technology leaders, practitioners, and GTM teams following the trends shaping modern software delivery.
Looking for deeper research access?
Explore ECI Research reports, survey insights, and market analysis through the ECI Research Portal.
