What it does
groundcover brings observability data such as metrics, logs, traces, events, and APM signals into a cloud-native monitoring service. Teams can define monitors in its web application, use catalog templates or YAML, and automate monitor creation through an API or Terraform provider. The Linux sensor is intended for eBPF-enabled hosts, so teams should check kernel requirements before planning coverage. Pricing includes a no-charge BYOC tier with short data retention and paid per-host plans.
From signal to monitor
groundcover's monitor workflow can start with a plain-language request or with a query you configure yourself. In the web application, open Monitor List or Issues and choose Create Monitor to use the Agent. An example for a test service might be to flag a sustained rise in billing-request latency, scope it to the billing workload, set a threshold and evaluation window, and route the alert to the on-call channel. The Agent creates a draft; inspect its query, threshold, issue details, and notification destination before saving. If you prefer a more explicit setup, the adjacent options include a blank monitor, a catalog template, and YAML import. The same guide documents API and Terraform approaches for teams that manage monitoring configuration as code.
The documented wizard supports several signal types, including metrics, logs, traces, events, APM, and ingestion volume. That lets a team alert on a service-level symptom or on a telemetry pipeline that suddenly stops delivering data. These monitors depend on the underlying signals being available in the workspace; for Linux hosts, the sensor guide requires an eBPF-enabled machine and lists AMD64 and ARM64 architectures. Check the kernel requirements for the machines you intend to cover rather than assuming every Linux host is supported.
Plan fit
The pricing page lists a free BYOC plan with no credit card required and 12-hour data retention, alongside paid per-host plans. That free retention window can be restrictive when an incident takes longer to investigate or a team needs older telemetry for comparison. The page also describes a full on-premises option, but the license terms for self-hosted components were not established in the pages reviewed. Pricing is plan and deployment dependent, so compare the current plan details against your retention needs before relying on it for long-lived operational history.
Strengths
- A single monitor can be built around metrics, logs, traces, events, APM, or ingestion data.
- Monitor creation supports an Agent-generated draft, a manual wizard, catalog templates, YAML import, an API, and a Terraform provider.
- The listed free BYOC plan requires no credit card and provides a way to evaluate the workflow with 12-hour retention.
Watch out for
- The Linux sensor requires an eBPF-enabled host and supported kernel; the guide lists AMD64 and ARM64 architectures.
- The free plan's 12-hour retention may be too short for investigations that need older telemetry.
Best for
- Platform teams that want to define workload alerts across Kubernetes or Linux telemetry and review monitor configuration before rollout.
- Teams using Terraform or an API to keep monitor definitions alongside operational configuration.
Sources
- The full-stack observability platform for engineers & agents (Oct 25, 2026)
- Create a new Monitor (Oct 25, 2026)
- Connect Linux hosts (Oct 25, 2026)
- groundcover Pricing Plans: Free, Team & Enterprise Plans (Oct 25, 2026)