groundcover Review 2026: eBPF-Based Kubernetes Observability
Honest hands-on review of groundcover — the eBPF-based Kubernetes observability platform. What you get out of the box, how it compares to Datadog and Dynatrace, real limitations, and a final verdict.
Most Kubernetes observability tools require you to add SDKs to your code, configure exporters in every service, or spend a week setting up dashboards. groundcover takes a different approach: deploy one Helm chart, and it maps your entire cluster using eBPF — no code changes, no restarts.
I ran it on a staging cluster for three weeks. Here is what I found.
What groundcover Is
groundcover (groundcover.com) is a SaaS observability platform specifically built for Kubernetes. It deploys a DaemonSet on every node that uses eBPF to intercept network traffic, system calls, and kernel events. From this, it reconstructs:
- Service maps (which services talk to which)
- HTTP/gRPC request traces (without OpenTelemetry SDK)
- Error rates and latency percentiles per endpoint
- Pod logs with automatic correlation to traces
- Infrastructure metrics (CPU, memory, network per pod)
All of this from a single Helm install, zero code changes.
Installation
helm repo add groundcover https://helm.groundcover.com
helm repo update
helm upgrade --install groundcover groundcover/groundcover \
--namespace groundcover \
--create-namespace \
--set global.apiKey="<your-api-key>" \
--set global.clusterId="production-cluster"That is literally it. Within 5 minutes of installing, the groundcover UI shows your service map populating in real time.
The DaemonSet uses roughly 100–150m CPU and 200–300Mi memory per node under normal load. On nodes with heavy HTTP traffic, I saw it peak at 400m CPU briefly.
What You Get Out of the Box
Service Map: Automatically discovered within minutes. Every service with network traffic shows up as a node. Edges show request rate, error rate, and p99 latency. You can filter by namespace, drill into a single service, or see the full cluster topology. No manual configuration.
Traces: HTTP and gRPC calls are captured at the kernel level. You get full request/response traces including headers, status codes, and payload sizes — without adding a single line of OpenTelemetry code. Traces correlate to the exact pod and show the full call path across services.
Logs: Pod logs are ingested automatically. The UI links log lines to traces by timestamp, so when you click on a slow trace, you can immediately see the relevant log lines from that pod during that window.
Alerts: Pre-built alert templates for error rate, latency, pod restarts, and OOMKilled. You configure thresholds; groundcover does the detection. PagerDuty and Slack integrations work out of the box.
Real Test: Finding a Latency Regression
I deployed a new version of an API service during my test. The service map immediately showed p99 latency on /api/users jumping from 45ms to 340ms. I clicked the endpoint, saw the traces, and noticed that calls to a downstream auth-service were taking 290ms — a new pattern that appeared with the deployment.
Without groundcover I would have needed Prometheus for the latency metric, Jaeger for the trace, and kubectl logs to correlate. Here it was one click.
How It Compares
| Feature | groundcover | Datadog | Dynatrace |
|---|---|---|---|
| Code instrumentation needed | None (eBPF) | Agent + SDK | Agent + OneAgent |
| Service map | Auto-discovered | Auto (with APM) | Auto (OneAgent) |
| Traces without SDK | Yes | Partial | Yes (OneAgent) |
| Kubernetes native | Yes — K8s only | General purpose | General purpose |
| Pricing model | Per node/hour | Per host + per GB | Per host (DEM units) |
| Self-hosted option | No (SaaS only) | No | Yes (Managed) |
| Setup time | ~5 minutes | 30–60 minutes | 1–2 hours |
| Log ingestion | Included | Extra cost | Included |
| RBAC / SSO | Yes | Yes | Yes |
vs. Datadog: Datadog is more mature and has better integrations (RDS, Lambda, synthetics). But it is significantly more expensive and requires more configuration to get the same auto-discovery. For a pure Kubernetes shop, groundcover is faster to value and cheaper.
vs. Dynatrace: Dynatrace also uses auto-instrumentation (OneAgent), but it is designed for large enterprise environments with complex pricing and a steeper learning curve. groundcover is simpler and faster for Kubernetes-focused teams.
vs. rolling your own (Prometheus + Grafana + Jaeger): The open-source stack is free but takes weeks to configure well and requires ongoing maintenance. groundcover's advantage is the correlation layer — linking metrics, traces, and logs together automatically. The open-source stack requires careful instrumentation to achieve the same correlation.
Real Limitations
SaaS only. There is no on-premises or self-hosted option. If your cluster is in a heavily regulated environment (financial services, government) with data residency requirements, this is a blocker.
eBPF requires kernel 4.18+. Most modern Linux distributions are fine (Ubuntu 20.04+, Debian 11+, Amazon Linux 2023). But if you are running older kernel versions in your nodes, you will need to upgrade before deploying groundcover.
No profiling. Datadog and Dynatrace include continuous profiling (CPU flame graphs per service). groundcover does not have this yet. If you need profiling, you will still need Pyroscope or Parca alongside.
Limited custom metrics. You cannot push arbitrary custom metrics from your application to groundcover the way you can with Datadog StatsD or Prometheus. It observes — it does not collect what you push. For custom business metrics (e.g., "orders per second by region"), you still need Prometheus.
Newer product. groundcover was founded in 2021. The product is solid for core use cases but does not have the breadth of integrations Datadog has after 15 years. Some AWS services (RDS, Elasticache, SQS) are not natively monitored.
Pricing
groundcover charges per node-hour. As of June 2026, pricing starts at roughly $25–40/node/month depending on contract length. For a 10-node cluster: $250–400/month. This compares to Datadog at $15/host/month for infrastructure plus $31/host/month for APM — so $460/month for 10 hosts with APM. groundcover is cheaper if you factor in the time you would spend configuring Datadog's APM.
They have a free tier for up to 3 nodes — worth using to evaluate before committing.
Verdict
Score: 8/10
groundcover is genuinely impressive for Kubernetes observability. The eBPF auto-discovery is not marketing fluff — it works, and it saves real engineering time. The service map, correlated traces, and logs are production-quality.
The gap is breadth. If you are 100% Kubernetes-native and do not need profiling, custom metrics pipelines, or self-hosting, groundcover is the fastest path to full observability. If you are running a mixed estate (Kubernetes + bare metal + Lambda + RDS) and need everything in one place, Datadog is still the safer choice — just more expensive.
Pick groundcover if:
- Your entire stack is on Kubernetes
- You want to be productive in hours, not weeks
- You are a team of 3–20 engineers without a dedicated observability engineer
- Budget matters and you want to avoid Datadog pricing at scale
Pick Datadog if:
- You have a mixed infrastructure (not just K8s)
- You need profiling, synthetics, or RUM
- You need self-hosted or on-premises deployment
- You are already deep in the Datadog ecosystem
Try It
Start with the free tier at groundcover.com — 3 nodes free, no credit card required. The Helm install takes under 10 minutes.
For self-hosted Kubernetes monitoring without SaaS, Grafana Cloud (free tier) + Prometheus + Tempo is still the open-source king.
Today I Fixed
Short real fixes from production — posted daily
Stay ahead of the curve
Get the latest DevOps, Kubernetes, AWS, and AI/ML guides delivered straight to your inbox. No spam — just practical engineering content.
Related Articles
AI-Powered Kubernetes Anomaly Detection: Beyond Static Thresholds
Static alerts miss 40% of real incidents. Learn how AI and ML-based anomaly detection — using tools like Prometheus + ML, Dynatrace, and custom LLM runbooks — catches what thresholds can't.
Build an AI-Powered SLO Breach Predictor with Claude and Prometheus
Build an SLO breach predictor that reads error budget burn rate from Prometheus, uses Claude to analyze patterns, and sends Slack alerts before SLOs breach — not after.
Build an AI Alert Classifier for Grafana Using LLMs (2026)
Tired of noisy Grafana alerts that wake you up for nothing? Build an AI layer that classifies incoming alerts as actionable or noise, enriches them with context, and routes them intelligently — using Claude or GPT-4 as the reasoning engine.