Overview

Our Log Management solution is built for high scale and fast query performance so you can analyze logs quickly and effectively from all your cloud environments.

Gain context - Each log data is enriched with actionable context and correlated with relevant metrics and traces in one single view so you can find what you’re looking for and troubleshoot, faster.

Centralize to maximize - The groundcover platform can act as a limitless, centralized log management hub. Your subscription costs are completely unaffected by the amount of logs you choose to store or query. It's entirely up to you to decide.

Collection

Seamless log collection

groundcover ensures a seamless log collection experience with our , which automatically collects and aggregates all logs in all formats - including JSON, plain text, NGINX logs, and more. All this without any configuration needed.

This sensor is deployed as a DaemonSet, running a single pod on each node within your Kubernetes cluster. This configuration enables the groundcover platform to automatically collect logs from all of your pods, across all namespaces in your cluster. This means that once you've installed groundcover, no further action is needed on your part for log collection. The logs collected by each sensor instance are then channeled to the OTel Collector.

OTel Collector: A vendor-agnostic way to receive, process and export telemetry data.

Acting as the central processing hub, the OTel Collector is a vendor-agnostic tool that receives logs from various sensor pods. It processes, enriches, and forwards the data into groundcover's ClickHouse database, where all log data from your cluster is .

Logs Attributes

Logs Attributes enable advanced filtering capabilities and is currently supported for the formats:

• JSON

• Common Log Format (CLF) - like those from NGNIX and Kong

• logfmt

groundcover automatically detects the format of these logs, extracting key:value pairs from the original log records as Attributes.

Each attribute can be added to your filters and search queries.

Example: filtering a log in a supported format with a field of a request path "/status" will look as follows: @request.path:"/status". Syntax can be found .

Configuration

groundcover offers the flexibility to craft tailored collection filtering rules, you can choose to set up filters and collect only the logs that are essential for your analysis, avoiding unnecessary data noise. For guidance on configuring your filters, explore our section.

You also have the option to for your logs in the ClickHouse database. By default, logs are retained for 3 days. To adjust this period to your preferences, visit our section for instructions.

Log Explorer

Once logs are collected and ingested, they are available within the groundcover platform in the Log Explorer, which is designed for quick searches and seamless exploration of your logs data. Using the Log Explorer you can troubleshoot and explore your logs with advanced search capabilities and filters, all within a clear and fast interface.

Search and filter

The Log Explorer integrates dynamic filters and a versatile search functionality that enables you to quickly and easily identify the right data. You can filter out logs by selecting one or multiple criteria, including log-level, workload, namespace and more, and can limit your search to a specific time range.

Log Pipelines

groundcover natively supports setting up log pipelines using This allow for full flexibility in the processing and manipulation of logs being collected - parsing additional patterns by regex, renaming attributes, and many more.

How much does groundcover cost?

groundcover's unique pricing model is the first to decouple data volumes from cost of owning and operating the solution. For example, subscribing to our costs $30 per node/host per month.

Overall, the cost of owning and operating groundcover is based on two factors:

• The number of nodes (hosts) you are running in the environment you are monitoring

The platform consolidates all your traces, metrics, logs, and Kubernetes events into a single pane of glass, allowing you to identify issues faster than ever before and conduct granular investigations for quick remediation and long-term prevention.

Our is not impacted by the volume of data generated by the environments you monitor, so you can dare to start monitoring environments that had been blind spots until now - such as your Dev and Staging clusters. This, in turn, provides you visibility into all your environments, making it much more likely to identify issues in the early stages of development, rather than in your live product.

groundcover introduces game-changing concepts to observability:

Overview

The groundcover platform collects data all across your stack using the power of eBPF instrumentation. Our proprietary eBPF sensor is installed
in seconds and provides 100% coverage into application metrics and traces with zero code changes or configurations.

Resolve faster - By seamlessly correlating traces with application metrics, logs, and infrastructure events, groundcover’s APM enables you to detect and resolve root issues faster.

Improve user experience - Optimize your application performance and resource utilization faster than ever before, avoid downtimes and make poor end-user experience a thing of the past.

Collection

Our revolutionary eBPF sensor, , is deployed as a DaemonSet in your Kubernetes cluster. This approach allows us to inspect every packet that each service is sending or receiving, achieving 100% coverage. No sampling rates or relying on statistical luck - all requests and responses are observed.

This approach would not be feasible without a resource-efficient eBPF-powered sensor. eBPF not only extends the ability to pinpoint issues - it does so with much less overhead than any other method. eBPF can be used to analyze traffic originating from every programming language and SDK - even for encrypted connections!

Reconstruction

After being collected by our eBPF code, the traffic is then classified according to its protocol - which is identified directly from the underlying traffic, or the library from which it originated. Connections are reconstructed, and we can generate transactions - HTTP requests and responses, SQL queries and responses etc.

Enrichment

In order to give as much context as possible each transaction is enriched with as much metadata as possible. Some examples might include the pods that took part in this transaction (both client and server), the nodes on which these pods are scheduled, and the state of container at the time of the request.

It is important to emphasize the impressive granularity level with which this process takes place - every single transaction observed is fully enriched. This allows us to perform more advanced aggregations.

Aggregation

After being enriched by as much context as possible, the transactions as grouped together into meaningful aggregations. These could be defined by the workloads involved, the protocols detected and the resources that were accessed in the operations. These aggregations will mostly come into play when displaying .

Exporting

After collecting the data, contextualizing it and putting it together in meaningful aggregations - we can now create and to provide meaningful insights into the services' behaviors.

Metrics

Learn how groundcover's application metrics work:

Traces

Learn how groundcover's application traces work:

The following architectures are fully supported for all groundcover workloads:

• x86

• ARM

These are patterns we've seen in the wild. Agents use groundcover to debug, monitor, and close the loop.

Test → Logs → Fix

Cursor generates tests, tags each with a test_id, logs them, and then uses groundcover to instantly fetch related log lines.

Investigate Issues via Cursor

Got a monitor firing? Drop the alert into Cursor. The agent runs a quick RCA, queries groundcover, and even suggests a patch based on recent logs and traces.

Support Workflow

Support rep gets an error ID → uses MCP to query groundcover → jumps straight to the root cause by exploring traces and logs around the error.

The Autonomous Loop

An agent picks up a ticket, writes tests, ships code to staging, monitors it with groundcover, checks logs and traces, and verifies the fix end to end. Yes, really. Full loop. Almost no hands.

groundcover enables access to an embedded Grafana, within the groundcover platform's interface. This enables you to easily import and continue using your existing Grafana dashboards and alerts.

The following guides will help you setup and import your visualizations from Grafana:

Create a Grafana dashboard

Build alerts & dashboards with Grafana Terraform provider

Using groundcover as Prometheus/Clickhouse database in a Self-hosted Grafana

Distribution Mode

In this mode, groundcover showcases the top attributes found in your traces or logs data. Each attribute displays up to four values with the highest occurrence across the selected traces.

You can click any value to add or exclude it as a filter and continue drilling down interactively.

How attributes are selected

We use statistical scoring based on:

• Entropy: how diverse the values of an attribute are.

• Presence ratio: how often the attribute appears across the selected traces.

Attributes that are both common and have high entropy are prioritized.

To ensure a seamless experience with groundcover, it's important to confirm that your environment meets the necessary requirements. Please review the detailed requirements for Kubernetes, our eBPF sensor, and the necessary hardware and resources to guarantee optimal performance.

Kubernetes requirements

groundcover supports a wide range of Kubernetes versions and distributions, including popular platforms like EKS, AKS, and GKE.

Learn more ->

Kernel requirements for eBPF sensor

Our state-of-the-art eBPF sensor leverages advanced kernel features to deliver comprehensive monitoring with minimal overhead, requiring specific Linux kernel versions, permissions, and CO:RE support.

Hardware and resource requirements

groundcover fully supports both x86 and ARM processors, ensuring compatibility across diverse environments.

ClickHouse resources

groundcover operates ClickHouse to support many of its core features. This requires suitable resources given to the deployment, which groundcover takes care of according to your data usage.

Structure of the Examples

• cURL-based examples: Every example shows the exact cURL command you can copy and run directly in your terminal.

• Endpoint-specific demonstrations: We walk through different API endpoints one by one, highlighting the required parameters and common use cases.

• Request & Response clarity: Each section contains both the request (what you send) and the response (what you get back) to illustrate expected behavior.

Prerequisites

Before running any of the examples, make sure you have:

Overview

The groundcover platform offers infrastructure monitoring capabilities that were built for cloud-native environments. It enables you to track the
health and efficiency of your infrastructure instantly, with an effortless deployment process.

Troubleshoot efficiently - acting as a centralized hub for all your infrastructure, application and customer metrics allows you to query, correlate and troubleshoot your cloud environments using real time data and insight on your entire stack.

Store it all, without a sweat - store any metrics volume without worrying about cardinality or retention limits.

The Monitor List is the central hub for managing and monitoring all active and configured Monitors. It provides a clear, filterable table view of your Monitors, with their current status and key details, such as creation date, severity, and live issues. Use this page to review your Monitors performance, identify issues, and take appropriate action.

Key Features

Once installed, we recommend following these steps to help you quickly gain the most our of groundcover's unique observability platform.

1. Get a complete view of your workloads

The "Home page" of the groundcover app is our Workloads page. From here, you can get a service-centric view,

A dashboard is a great tool for visually tracking, analyzing, and displaying key performance metrics, which enable you to monitor the health of your infrastructure and applications.

Supercharge your AI agents with o11y superpowers using the groundcover MCP server. Bring logs, traces, metrics, events, K8s resources, and more directly into your agent’s context — and troubleshoot side by side with your AI assistant to solve issues in minutes.

Status: Work in progress. We keep adding tools and polishing the experience. Got an idea or question? Ping us on Slack!

What is MCP?

MCP (Model Context Protocol) is an open standard that enables AI tools to access external data sources like APIs, observability platforms, and documentation directly within their working context. MCP servers expose these resources in a consistent way, so the AI agent can query and use them as needed to streamline workflows.

Automated migration from legacy vendors. Bring over your monitors, dashboards, data sources, and all the data you need - with automatic mapping and zero downtime.

Overview

groundcover is the first observability platform to ship a one-click migration tool from legacy vendors. The migration flow automatically discovers, translates, and installs your observability setup into groundcover.

Goal: Move your entire observability stack with zero manual work. We don't just migrate assets - we bring the data and handle all the mapping for you.

groundcover insights give you a clear snapshot of notable events in your data. Currently, the platform supports Error Anomalies, with more insight types on the way.

Error Anomalies

Error Anomalies instantly highlight workloads, containers, or environments experiencing unusual spikes in Error or Critical logs, as well as Traces marked with an error status. These anomalies are detected using statistical algorithms, continuously refined through user feedback for accuracy.

Each insight surfaces trends based on the entity’s error signals (e.g., workload, container, etc.):

This section contains comprehensive examples of webhook integrations with various third-party services. These examples provide step-by-step instructions for setting up complete workflows with external systems.

Available Examples

• - Integrate with incident.io for incident management

groundcover enables access to an embedded Grafana, within the groundcover platform's interface. This enables you to easily import and continue using your existing Grafana and alerts.

Raw Prometheus API

You can obtain your API key from the in the groundcover console.

You can query the Prometheus API directly using curl:

For complete Prometheus REST API documentation, see:

Overview

The Monitor Catalog is a library of pre-built templates to efficiently create new Monitors. Browse and select one or more Monitors to quickly configure their environment with a single click. The Catalog groups monitors into "Packs", based on different use cases.

Labeling clusters in your cloud-native environments is very helpful for efficient resource management and observability. By assigning an environment label in groundcover, you can categorize and identify clusters based on any specific criteria that you find helpful. For example, you can choose to label your clusters by environment type (development, staging, production, etc.), or by region (EU, US, etc.).

To add an environment label to your cluster, edit your cluster's existing values.yaml and add the following line:

Once defined and added, these labels will be available for you to select in the cluster and environment drop down menu ("Cluster Picker").

Summary

Service accounts in groundcover are non-human identities used for programmatic access to the API. They’re ideal for CI pipelines, automation, and backend services, and are governed by groundcover’s RBAC system.

Endpoint

DELETE /api/workflows/{id}

Authentication

This endpoint requires API key authentication.

Headers

Path Parameters

Example Request

Response

Success Response

Status Code: 200 OK

Notes

• Once a workflow is deleted, it cannot be recovered

• The deletion is immediate and permanent

• All associated workflow executions and history are also removed

• The API returns HTTP 200 status code for both successful deletions and "not found" cases

Configure the Grafana Terraform provider

For instructions on how to generate a Grafana Service Account Token and use it in the Grafana Terraform provider, see: Grafana Service Account Token.

Dashboard provisioning example

• Create a directory for the terraform assets

• Create a main.tf file within the directory that contains the terraform provider configuration mentioned in step 2

• Create the following dashboards.tf file, this example declares a new Golden Signals folder, and within it a Workload Golden Signals

• add the workloadgoldensignals.json file to the directory as well

• Run terraform init to initialize terraform context

• Run terraform plan , you should see a long output describing the assets that are going to be created last line should state Plan: 2 to add, 0 to change, 0 to destroy.

• Run terraform apply

Here is a short video to demonstrate the process

You can read more about what you can achieve with the Grafana Terraform provider in the

Overview

The Silences page lists all Silences you and your team created for your Monitors. In this section, you can also create and manage your Silence rules, to suppress notifications and Issues noise, for a specified period of time. Silences are a great way to reduce alert fatigue, which can lead to missing important issues, and help focus on the most critical issues during specific operational scenarios such as scheduled maintenances.

Create a new Silence

Follow these simple steps to create a new Silence.

Section 1: Schedule

Specify the timeframe for the silence rule. Note that the starting point doesn't have to be now, and can also be any time in the future.

Below the From / Until boxes, you'll see a Silence summary, showing its approximate length (rounded down to full days) and starting date.

Section 2: Matchers

Define the criteria for Monitors or Issues to be silenced.

1. Click Add Matcher to specify match conditions (e.g., cluster, namespace, span_name).

2. Combine multiple matchers for more granular control.

Example: Silence all Monitors in the "demo" namespace.

Section 3 - Affected Active Issues

Preview the issues currently affected by the Silence rule, based on any defined Matchers. This list contains only actively firing Issues.

Tip: Us this preview to see the list of impacted issues and adjust your Matchers before finishing to create the Silence.

Section 4: Comment

Add notes or context for the Silence rule. These comments help you and other users understand the purpose of the rule.

groundcover’s dashboards are designed to personalize your data visualization and maximize the value of your existing data. Dashboards are perfect for creating investigation flows for critical monitors, displaying the data you care about in a way that suits you and your team, and crafting insights from the data on groundcover.

Easily create a new Dashboard using our guide.

Key Features

• Multi-Mode Query Bar: The Query Bar is central to dashboards and supports multiple modes fully integrated with native pages and Monitors. Currently, the modes include Metrics, Infra Metrics, Logs, and Traces. Learn more in the .

• Variables: Built-in variables allow you to filter data quickly based on a predefined list crafted by groundcover.

• Widget Types: Two widget types are currently supported:

  • Chart Widget: Displays data visually.

  • Textual Widget: Adds context to your dashboards.

• Display Types: Five display types are supported for data visualization:

  • Time Series, Table, Stat, Top List, and Pie. Read more in the

Filtering out specific resources

The following example will filter out all HTTP traces that include the /health URI. Note that the filter transform works by setting up an allow condition - meaning, events which fail the condition will be dropped.

The filter below implements this logic:

1. If the event isn't an HTTP event, allow it

2. If the event is an HTTP event, and the resource name doesn't contain "/health", allow it

3. If the event is an HTTP event AND it has "/health" in the resource name, drop it

Redact payloads from a specific server

The following example will obfuscate response payloads from a specific server. This can be useful when you want to completely redact responses that contain sensitive data, such as secrets managed by an external server.

Redact payloads based on a header value

In this example we redact HTTP payloads for any request containing the host: frontend header.

Monitors offers the ability to define custom alerts, which you can configure using groundcover data and custom metrics.

What is a Monitor

A Monitor defines a set of rules and conditions that track the state of your system. When a monitor's conditions are met, it triggers an issue that is displayed on the Issues page and can be used for alerting using your integrations and workflows.

Easily create a new Monitor by using our guide.

Supported Environments

We currently support running on eBPF-enabled linux machines (See more

The legacy Issues page is being deprecated in favor of a fully customizable, monitor-based experience that gives you more control over what constitutes an issue in your environment.

While the new page introduces powerful capabilities, no core functionality is being removed, the key change is that the old auto-created issue rules will no longer be automatically generated. Instead, you’ll define your own monitors, or choose from a rich catalog of prebuilt ones.

All the existing issues in the legacy page can be easily added to the monitors via the Monitors Catalog's "Started Pack". See below for more info.

Why migrate to the new Issues experience?

The new Issues page is built on top of the Monitors engine, enabling deeper customization and automation:

Sign up to groundcover

The first thing you need to do to start using groundcover is using your email address (no credit card required for the free tier account). Signing up is only possible using a computer and will not be possible using a mobile phone or tablet. It is highly recommended you use your corporate email address, as it will make it easier to use other features such as inviting your colleagues to your workspace. However, signing up using Gmail, Outlook or any other public domains is also possible.

An API key in groundcover provides secure, programmatic access to the API on behalf of a service account. It inherits that account’s permissions and should be stored safely

Binding and Permissions

Each API key is tied to a specific service account. It inherits the permissions defined by that account’s RBAC policies. Optionally, the key can be limited to a subset of those policies for more granular access control. An API key can never exceed the permissions of its parent service account.

Once your MCP server is connected, you can dive right in.

Here are a few prompts to try. They work out of the box with agents like Cursor, Claude, or VS Code:

💡 Starting your request with “Use groundcover” is a helpful nudge - it pushes the agent toward MCP tools and context.

Basic Prompts to Try

MCP supports complex, multi-step flows, but starting simple is the best way to ramp up.

The Issues page provides a detailed view of active and resolved issues triggered by Monitors. This page helps users investigate, analyze, and resolve problems in their environment by visualizing issue trends and providing in-depth context through an issue drawer.

Issues drawer

Clicking on an issue in the Issues List opens the Issue drawer, which provides an in-depth view of the Monitor and its triggered issue. You can also navigate if possible to related entities like workload, node, pod, etc.

groundcover provides a robust user interface that allows you to view and analyze all your observability data from inside the platform. However, there may be cases in which you need to query the data from outside our platform using API communication.

Our proprietary eBPF sensor automatically captures granular observability data, which is stored via our integrations with two best-of-breed technologies. VictoriaMetrics for metrics storage, and ClickHouse for storage of logs, traces, and Kubernetes events.

Read more about our architecture .

Generate the API key

Run the following command in your CLI, and select tenant:

groundcover auth get-datasources-api-key

Step 1 - generate Grafana Service Account Token

• Make sure you have

Workflows are YAML-based configurations that are executed whenever a monitor is triggered. They enable you to integrate with third-party systems, apply custom logic to format and transform data, and set different conditions to handle your monitoring alerts intelligently.

Workflow components

Triggers

Creation

Creating new workflows is currently supported through the groundcover app in two ways from the Monitors menu:

1. - An API key in groundcover provides secure, programmatic access to the API on behalf of a . It inherits that account’s permissions and should be stored safely. This is also the key you need when working groundcover’s terraform provider. See:

   1. groundcover's .

   2. groundcover's Terraform provider: .

groundcover is designed to support data ingestion from multiple sources, giving you comprehensive observability across your entire stack. Choose the installation method that best fits your infrastructure and monitoring needs.

Available Installation Options

Structure

Kubernetes version

groundcover supports any K8s version from v1.21.

Kubernetes distributions

Kubernetes RBAC permissions

For the installation to complete successfully, permissions to deploy the following objects are required:

• StatefulSet

• Deployment

• DaemonSet (With privileged containers for loading our )

• ConfigMap

To learn more about groundcover's architecture and components visit our

Outgoing traffic

groundcover's portal pod sends HTTP requests to the cloud platform app.groundcover.com on port 443.

This unique keeps the the data inside the cluster and fetches it on-demand keeping the data encrypted all the way without the need to open the cluster for incoming traffic via ingresses.

Set up your agent to talk to groundcover’s MCP server. Use OAuth for a quick login, or an API key for service accounts.

The MCP server supports two methods:

• OAuth (Recommended for IDEs)

• API Key

OAuth (recommended)

OAuth is the default if your agent supports it.

To get started, add the config below to your MCP client. Once you run it, your browser will open and prompt you to log in with your groundcover credentials.

Configuration Example

Cursor

Claude Code

API Key

If your agent doesn’t support OAuth, or if you want to connect a service account, this is the way to go.

Prerequisites

1. Service‑account API key – create one or use an existing API Key. Learn more at .

2. Your local time zone (IANA format, for example America/New_York or Asia/Jerusalem). See how to .

Configuration Example

Parameters

• AUTH_HEADER – your groundcover API key.

• TIMEZONE – your time zone in IANA format.

Have a Multi‑backend setup?

If you're using a multi-backend setup (OAuth or API Key), just add the following header to the args list:

First, grab your backend ID (it’s basically the name):

1. Open Data Explorer in groundcover.

2. Click the Backend picker (top‑right) and copy the backend’s name.

How to find your time zone

Client‑specific Guides

Depending on your client, you can usually set up the MCP server through the UI - or just ask the client to add it for you. Here are quick links for common tools:

Intro

groundcover’s eBPF sensor uses state-of-the-art kernel features to provide full coverage at low overhead. In order to do so it requires certain kernel features which are listed below.

Kernel Version

Version v5.3 or higher (anything since 2020).

Linux Distributions

Permissions

Loading eBPF code requires running privileged containers. While this might seem unusual, there's nothing to worry about - eBPF is

CO:RE support

Our sensor uses eBPF’s feature in order to support the vast variety of linux kernels and distributions detailed above. This feature requires the kernel to be compiled with BTF information (enabled using the CONFIG_BTF_ENABLE=Y kernel compilation flag). This is the case for most common nowadays.

You can check if your kernel has CO:RE support by manually looking for the BTF file:

If the file exists, congratulations! Your kernel supported CO:RE.

What happens if my kernel is not supported?

If your system does not fit into any of the above - unfortunately, our eBPF sensor will not be able to run on your environment. However, this does not mean groundcover won’t collect any data. You will still be able to inspect your , see all and use with outer data sources.

This guide shows how to route groundcover alerts to email using Zapier. Since groundcover supports webhook-based alerting, and Zapier can receive webhooks and send emails, you can easily set up this workflow without writing code.

Prerequisites

• A groundcover account with access to the Workflows tab.

• A Zapier account (free plan is sufficient).

• An email address where you want to receive alerts.

Step 1: Create a Webhook Integration in groundcover

1. Go to Settings → Integrations.

2. Click Create Integration.

3. Choose Webhook as the type.

4. Enter a name like zapier_email_integration.

Step 2: Create a Zapier Webhook-to-Email Workflow

Create a Webhook Trigger

1. Go to .

2. Click "Create Zap".

3. Set Trigger:

   • App: Webhooks by Zapier

Configure the Email Step

1. Set Action:

   • App: Email by Zapier

   • Event: Send Outbound Email

Step 3: Create a Workflow in groundcover

1. Go to the Workflows section in your groundcover.

2. Create a Notification Workflow with the integration we created in step 1.

3. Edit the worflow YAML and use the following structure:

Step 4: Test the Flow

1. Trigger a test alert in groundcover.

2. Check Zapier to ensure the webhook was received.

3. Confirm the email arrives with the right content.

Endpoint

Authentication

This endpoint requires API Key authentication via the Authorization header.

Headers

Request Body

Time Range Parameters

• Format: ISO 8601 format with milliseconds: YYYY-MM-DDTHH:mm:ss.sssZ

• Timezone: All timestamps must be in UTC (denoted by 'Z' suffix)

Response

The response contains an array of namespaces for the specified time period.

Response Fields

Examples

Basic Request

Response Example

Time Range Usage

Last 24 Hours

The issues page is a useful place to start a troubleshooting or investigation flow from. It gathers together all active issues found in your Kubernetes environment.

Issue Types

• HTTP / gRPC Failures Capturing failed HTTP calls with Response Status Codes of:

  • 5XX — Internal Server Error

  • 429 — Too Many Requests

• MySQL / PostgreSQL Failures

  Capturing failed SQL statement executions with Response Errors Codes such as:

  • 1146 — No Such Table

• Redis Failures Capturing any reported Error by the Redis serialization protocol (RESP), such as:

  • ERR unknown command\

• Container Restarts Capturing all container restart events across the cluster, with Exit Codes such as:

  • 0 — Completed

  • 137 — OOMKilled\

• Deployment Failures

  Capturing events such as:

  • MinimumReplicasUnavailable — Deployment does not have minimum availabiltiy

Issue Aggregation

Issues are auto-detected and aggregated - representing many identical repeating incidents. Aggregation help cutting through the noise quickly and reach insights like when a new type of issue started to appear, and when it was last seen.

Issues are grouped by:

• Type (HTTP, gRPC, Container Restart, etc..)

• Status Code / Error Code (e.g HTTP 500, gRPC 13)

• Workload name

The smart aggregation mechanism will also identify query parameters, remove them, and group the stripped queries / API URIs into patterns. This allows users to easily identify and isolate the root cause of a problem.

Troubleshooting with Issues

Each issue is assigned a velocity graph showing it's behavior over time (like when it was first seen) and a live counter of its number of incidents.

By clicking on an issue, users can access the specific traces captured around the relevant issue. Each trace is related to the exact resource that was used (e.g. raw API URI, or SQL query), it's latency and Status Code / Error Code.

Further clicking on a selected captured trace allows the user to investigate the root cause of the issue with the entire payload (body and headers) of the request and response, the information around the participating container, the application logs around incident's time and the full context of the metrics around the incident.

Below are the essentials relevant to writing remap transforms in groundcover. Extended information can be found in Vector's documentation.

Working with fields and attributes

When processing Vector events, fields names need to be prefixed by . , a single period. For example, the content field in a log, representing the body of the log, is accessible using .content. Specifically in groundcover, attributes parsed from logs or associated with traces will be stored under the string_attributes for string values, and under float_attributes for numerical values. Accessing attributes is possible by adding additional . as needed. For example, a JSON log that looks like this:

Will be translated into an event with the following attributes:

Fallible functions

Each of Vector's built-in function can be either fallible or infallible. Fallible functions can throw an error when called, and require error handling, whereas infallible functions will never throw an error.

When writing Vector transforms in VRL it's important to use error handling where needed. Below are the two ways error handling in Vector is possible - see more on .

Option #1 - Handling the error

Let's take a look at the following code.

The code above can either succeed in parsing the json, or fail in parsing it. The err variable will contain indication of the result status, and we can proceed accordingly.

Option #2 - Aborting on error

Let's take a look at this slightly different version of the code above:

This time there's no error handling around, but ! was added after the function call.

This method of error handling is called abort on error - it will fail the transform entirely if the function returns an error, and proceed normally otherwise.

Choosing which method to use

Both methods above are valid VRL for handling errors, and you must choose one or the other when handling fallible functions. However, they carry one big difference in terms of pipelines in groundcover:

• Transforms which use option #1 (error handling) will not stop the pipeline in case of error - the following steps will continue to execute normally. This is useful when writing optional enrichment steps that could potentially fail with no issue.

• Transforms which use option #2 (abort) will stop the pipeline in case of error - the event will not proceed to the other steps. This is mostly useful for mandatory steps which can't fail no matter what.

Endpoint

POST /api/pipelines/logs/config

Authentication

This endpoint requires API Key authentication via the Authorization header.

Headers

Examples

Basic Request

Update logs pipeline configuration with test pattern:

Response Example

🚨 CRITICAL WARNING: This endpoint COMPLETELY REPLACES the entire pipeline configuration and WILL DELETE ALL EXISTING RULES. Always backup your current configuration first by calling the GET endpoint.

Backup Current Configuration First

ALWAYS get your current configuration before making changes:

Verify Configuration Update

After updating the configuration, verify the patterns were added:

This should return your updated configuration including the new test patterns.

Related Documentation

For detailed information about configuring and writing OTTL transformations, see:

Endpoint

GET /api/pipelines/logs/config

Authentication

This endpoint requires API Key authentication via the Authorization header.

Headers

Examples

Basic Request

Get current logs pipeline configuration:

Response Example

Related Documentation

For detailed information about configuring and writing OTTL transformations, see:

Create & manage dashboards with Terraform

Use Terraform to create, update, delete, and list groundcover dashboards as code. Managing dashboards with infrastructure‑as‑code (IaC) lets you version changes, review them in pull requests, promote the same definitions across environments, and detect drift between what’s applied and what’s running in your account.

Ingestion Keys let sensors, integrations and browsers send observability data to your groundcover backend. They are the counterpart of API Keys, which are optimized for reading data or automating dashboards and monitors.

Key types

Endpoint

DELETE /api/rbac/ingestion-keys/delete

To integrate groundcover with MS Teams, follow the steps below. Note that you’ll need at least a Business subscription of MS Teams to be able to create workflows.

1. Create a webhook workflow for your dedicated Teams channel Go to Relevant Team -> Specific Channel -> "Workflows", and create a webhook workflow

2. The webhook workflow is associated a URL which is used to trigger the MS Teams integration on groundcover - make sure to copy this URL

3. Set Up the Webhook in groundcover

groundcover’s Real User Monitoring (RUM) SDK allows you to capture front-end performance data, user events, and errors from your web applications.

Start capturing RUM data by installing the in your web app.

This guide will walk you through installing the SDK, initializing it, identifying users, sending custom events, capturing exceptions, and configuring optional settings.

To integrate groundcover with , follow the steps below. Note that you’ll need a Pro incident.io account to view your incoming alerts.

1. Generate an Alerts configuration for groundcover Log in to your account. Go to "On-call" -> "Alerts" -> "Configure" and add a new source.

2. On the "Create Alert Source" screen the answer to the question "Where do your alerts come from?" should be "HTTP". Select this source and give it a unique name. Hit "continue".

groundcover supports sending notifications to Slack using a Slack App with bot tokens instead of static webhooks. This method allows dynamic routing of alerts to any channel by including the channel ID in the payload. In addition to routing, messages can be enriched with formatting, blocks, and mentions — for example including <@user_id> in the payload to directly notify specific team members. This provides a flexible and powerful alternative to fixed incoming webhooks for alerting.

Make sure you created a .

Use the following workflow as an example. You can later enrich your workflow with additional functionality.

Here are a few tips for using the example workflow:

1. In the consts section, the channels attribute defines the mapping between Slack channels and their IDs. Use a clear, readable label to identify each channel (for example, the channel’s actual name in Slack), and map it to the corresponding channel ID.

Overview

Terraform is an infrastructure-as-code (IaC) tool for managing cloud and SaaS resources using declarative configuration. The groundcover Terraform provider enables you to manage observability resources such as policies, service accounts, API keys, and monitors as code—making them consistent, versioned, and automated.

We've partnered up with Hashicorp as an official Terraform provider-

Also available is our provider Github repository:

groundcover uses as its underlying metrics storage solution. As such, groundcover integrates seamlessly with VictoriaMetrics and tools.

Doing incremental backups

groundcover exposes data sources for programmatic access via API, and integration with customer owned Grafana instances.

A Saved View captures your current page layout: filters, columns, toggles, etc.. so you and your team can reopen the page with the same context every time. Each groundcover page maintains its own catalogue of views, and every user can pick their personal Favorites.

Where to find them

On the pages: Traces, Logs, API Catalog, Events.

Look for the Views selector next to the time‑picker. Click it to open the list, create a new view, or switch between existing ones.

Capture real end-user experiences directly from their browsers and unify these insights with your backend observability data.

➡️ Check out our to your platform.

groundcover supports the configuration of logs and traces pipelines, to further process and customize the data being collected, using transforms. This enables full flexibility to manipulate the data as it flows into the platform.