Groundcover's $100M Series C Rewrites the Observability Buy Decision

Every VP Engineering with a Datadog or New Relic renewal landing in the next two quarters just got a new data point to walk into the CFO's office with. Groundcover, a Tel Aviv observability vendor built on eBPF and OpenTelemetry, closed a $100 million Series C the week of July 31. The round matters less for what it says about Groundcover and more for what it says about the shape of the observability line item on your 2027 budget.

What Happened

As Network World reported, Groundcover's Series C was led by One Peak, with participation from Morgan Stanley Expansion Capital, Zeev Ventures, Angular Ventures, Heavybit, and Jibe. That brings total funding to $160 million for a company founded in 2021. The round follows a $35 million Series B in April 2025, so the pace here is aggressive: roughly fifteen months between B and C, and nearly triple the round size.

The company's pitch, in the words of CEO and co-founder Shahar Azulay, is that observability is undergoing a category shift. "I think what is happening to observability right now is fascinating," he told Network World. The technical bet is that eBPF, the extended Berkeley Packet Filter kernel technology that lets code run safely inside the Linux kernel without a custom module, gives Groundcover a vantage point that SDK-based instrumentation can't match. The commercial bet is that telemetry from agentic AI workflows is going to explode in volume and sensitivity, and enterprises will not want to ship it to a shared vendor backend.

That second bet is why Groundcover stores telemetry inside the customer's own cloud environment. It's also why the company has been busy building AI-adjacent product: Agent Mode, a built-in assistant that lets engineers build dashboards and troubleshoot logs and traces without hand-writing queries, plus a Model Context Protocol integration that connects Agent Mode to coding agents and workflow tools including Linear. Azulay said MCP adoption moved faster than the company expected.

Technical Anatomy

Two architectural choices are doing the heavy lifting here, and platform leads should understand both before they nod along to the vendor pitch.

The first is eBPF as the collection layer. Traditional observability requires developers to instrument code, import an SDK, and emit telemetry the vendor understands. That model breaks the moment your engineers start wiring up LangChain agents, MCP servers, and third-party model vendors that nobody catalogued. "eBPF is kind of that security net of even if you didn't instrument, even if you're not in full control, you're gonna know which agentic workflows are running in production, which models are using, which vendors they're using," Azulay said. Running below the application layer means the observability tool sees traffic and syscalls regardless of whether the app team remembered to add tracing. For teams shipping AI features on Kubernetes, that's the difference between knowing your token spend and getting surprised by it at end of quarter.

The second is bring-your-own-cloud storage. Most SaaS observability vendors ingest customer telemetry into a multi-tenant backend they operate. That works fine for HTTP request logs. It works badly when traces contain, as Azulay pointed out, a customer's actual prompt instead of only structured request data. Prompts are user content. Depending on your jurisdiction and vertical, they may also be regulated content. Keeping telemetry inside the customer VPC changes the data residency conversation from a vendor questionnaire into an architecture diagram.

The third shift, which is really a consequence of the first two, is what teams measure. Latency and error rate are still there. Now token usage and hallucination rates sit alongside them. Distributed tracing, which assumed a predictable number of hops between services, has to accommodate a single agent session that fans out into dozens of tool calls and internal model calls with no fixed pattern. Azulay is explicit that this is not a rebadged APM product. "It's not going to be the same product. AI observability is not exactly APM."

Who Gets Burned

The incumbents. If AI observability really is a different product category rather than a feature bolt-on, then Datadog, New Relic, Splunk, and Dynatrace are in the position that on-prem monitoring vendors were in around 2015: still selling the old thing, watching a new thing get funded around them. That doesn't mean they lose. It means their per-host and per-GB pricing models start looking wrong for workloads where a single agent trace can carry a multi-kilobyte prompt payload.

The CFO at any series-B or later company with meaningful AI feature spend should be asking the VP Engineering this week a specific question: what percentage of our observability bill is now driven by AI workload telemetry, and is that line growing faster than the underlying compute? If yes, the renewal conversation with the current vendor isn't a renewal conversation. It's a re-architecture conversation, and the use sits with whoever brings the alternative quote.

Engineering teams also get burned in a subtler way. If your platform team standardized on SDK-based instrumentation two years ago and wrote internal libraries wrapping the vendor client, an eBPF-based approach doesn't slot in cleanly. You either run both (double the cost, double the confusion) or you commit to a migration project that eats a quarter of platform capacity. Neither is free.

The hiring market shifts too. Observability engineers who understand eBPF, kernel-level tracing, and OpenTelemetry pipelines have been rare and expensive. Add MCP integration experience and prompt-aware telemetry design, and you're looking at a small candidate pool that Groundcover, Chronosphere, Honeycomb, and every AI-native startup will be competing for. Budget accordingly.

Playbook for Engineering Teams

First, audit what your current observability vendor actually captures from your AI workloads. If the answer is "whatever our developers manually instrument," you have a visibility gap that will show up as a production incident before it shows up as a line item. Azulay compared the current AI visibility gap to the pre-observability era of roughly a decade ago. He's not wrong, and teams that lived through that transition remember how much of the pain was self-inflicted through delayed tooling decisions.

Second, pull your General Counsel into the observability conversation. If traces now contain customer prompts, your data processing agreements with your observability vendor need to reflect that. A shared multi-tenant backend holding prompt content is a different regulatory posture than structured request metadata. Bring-your-own-cloud architectures are worth the operational overhead if they take a compliance conversation off the table.

Third, treat MCP integration as a real evaluation criterion, not a demo bullet. The pattern Azulay described, where some customers query observability through MCP instead of the dashboard while others use it to write fixes directly, is going to be how on-call actually works within eighteen months. Vendors without a credible MCP story are quietly being deprioritized in enterprise RFPs already.

Fourth, model the unit economics. Cost per trace, cost per GB retained, cost per active agent. If your AI feature roadmap has you tripling agent volume next year, run that number against your current contract before you sign anything longer than twelve months.

Key Takeaways

• Groundcover's $100M Series C, led by One Peak, brings total funding to $160M and validates AI observability as a distinct category from traditional APM.
• eBPF-based collection removes the SDK instrumentation step, which matters more as engineering teams lose track of which agentic workflows and model vendors are running in production.
• Bring-your-own-cloud telemetry storage is becoming a regulatory requirement, not a preference, once traces start carrying raw customer prompts.
• Token usage and hallucination rate are now first-class observability metrics alongside latency and error rate. Vendor contracts written before this shift are priced wrong.
• MCP integration adoption is running ahead of vendor expectations. Teams evaluating observability platforms this quarter should be asking how the vendor's AI assistant hands context to coding agents, not whether it has one.