top of page

groundcover

Case study: Bringing Log Rule Editing into the Product UI

Project Overview

groundcover is a cloud-native observability platform, helping engineers monitor and understand what's happening across complex infrastructure in real time. One of its core capabilities is log management: machine-generated messages that reveal how software behaves. groundcover uses a low-level technology called eBPF sensors to automatically capture all logs from a system. This approach is powerful, but it can also overwhelm users with excessive, unstructured data.

Client

groundcover

Industry

Observability platform, DevOps, SaaS

My role

Product designer (user interface, user experience)

Main screen _ Logs.png
The Problem

When groundcover collects all logs by default, users face two major challenges:

  1. Too much irrelevant data. Many logs are noisy or unnecessary, and users need a way to filter them out.

  2. Unreadable formats. Some logs arrive in unstructured text, making them difficult to parse or search.

 

Before this project, the only way to manage logs was by editing configuration files using a scripting format called OTTL. This method was manual, error-prone, and disconnected from the product UI. Users had the power, but not the usability.

Chart 1.png
The Goal

The design goal was to create an experience that allows users to choose which logs to keep or drop, control how logs are structured and parsed, and do everything inside the groundcover UI without writing code. The solution needed to support expert-level flexibility while remaining accessible and intuitive for daily use.

Chart 2.png
Research & Competitive Exploration

To inform the initial direction, I conducted a competitive audit of observability and log analysis tools (e.g., Datadog, Coralogix, Open Telemetry). While many platforms offer advanced rule engines, they often require steep learning curves or depend on rigid syntax. I mapped key UX patterns and pain points across these tools to identify opportunities for a more guided, intuitive rule creation experience.

Chart 6.png
Process

I identified two key user scenarios:

  1. Reactive flow. Users are investigating an issue, encounter a problematic log, and want to fix or filter it on the spot.

  2. Proactive flow. Users are configuring the system more broadly and need an overview of all parsing rules to manage and refine them.

I collaborated with product managers and developers to map current pain points and understand user mental models around logs and rule creation.

Chart 3.png
Chart 4.png

Iterations

Stage 1 

Parsing Playground

The initial version was a playground environment where users could write and preview parsing logic. Although there was no way to save or apply rules in the UI, the playground helped validate user intent. 

Add Parsing Rule 1.png

One feature that stood out was the addition of an LLM-assisted which helped users generate rule configuration quickly. This early success demonstrated that AI-assisted configuration could lower the barrier for working with complicated rule formats. 

Stage 2

Inline editing and Parsing Pipelines settings page

In the second iteration, we introduced two key components at once. First, we added direct actions on individual log entries: "Create Drop Rule" and "Add Parsing Rule," giving users the ability to act from the exact log they were reviewing.

Frame 1261157353.png

Simultaneously, we launched the Parsing Pipelines settings page, a central dashboard showing all active rules along with system-level metrics such as drop rate and error count. While this brought much-needed visibility, it did not yet allow users to create new rules independently from the settings view.

Parsing Pipelines.png

Upcoming

Stage 3 

Query Builder for Settings

The next planned iteration will allow users to create and edit parsing pipelines directly from the Settings screen, without needing to start from a specific log entry. This will include a query builder to help users search and filter logs before building a rule. This step aims to complete the experience by supporting full rule creation from both reactive and proactive workflows.

Builder Mode 2.png

Final Design

The final design supported both reactive and proactive workflows. Users could take action directly from the Logs view with inline log actions, such as dropping or editing logs while staying in context. The Parsing Pipelines settings page served as a centralized dashboard that displayed all existing rules with performance metrics like drop rate and error count, while also allowing users to edit or delete rules as needed. Together, these elements created a smooth and effective experience for users managing log parsing through the UI.

Light.png

Reactive flow

Add Parsing Rule

Creating configuration 

Add to Logs Pipeline.png

Place rule order in pipeline

Proactive flow

Parsing Pipelines.png

Settings page

Drag & Drop.png

Reorder pipelines

Fleet Manager is not enabled.png

Empty state - not connected

Impact

This release brought log parsing directly into the groundcover UI, allowing users to manage their log configuration without needing to edit code or contact support. It turned a previously manual process into a self-serve experience.

The project improved user control, cut friction, and created a solid foundation for future features. By shipping in steps, we tested, learned, and improved quickly. Supporting both in-the-moment actions and planned changes made the system more flexible and user-friendly.

Chart 5.png
Dark.png

And yes!
We do have
dark mode

bottom of page