Error Tracking

142 events, one issue

Exceptions are grouped by what they are, not by how many times they happened. Each issue keeps its first occurrence, its latest, and the span that threw every one of them.

Start free trial

The surface

Grouped, counted, and still traceable

The list is issues, not events — each row carrying its type, the services it hits, its count over the range and when it was last seen.

Errors grouped by type with counts, affected services and last-seen times

/errors ConnectionTimeout · payment-svc

groups.by: exception.type + message
normalises: id · timestamp · host · port
per.issue: first · last · count · services
joins.on: trace_id · span_id
severity: manual > detector > ai
detector: 5 min

What it does

From an issue to a fix

Grouping: ConnectionTimeout out of payment-svc is one issue, not 142 events. The fingerprint is exception.type plus the message with ids, timestamps and hosts normalised out.
The span that threw it: An error is an event on a span, so every issue opens the trace it belongs to — with the arguments, the query and the status code that were live at the time.
New, or new again: Issues carry first-seen and last-seen, so a regression reads differently from a first appearance. A resolved issue that fires again reopens rather than starting over.
Owned by someone: Claim an issue, set its severity, leave the note. State and comments live with the issue, so the next person on call reads what you already ruled out.
Triaged before you wake: A detector runs every five minutes and sets a severity from the issue's own rate and spread. Manual severity always wins over the detector's, and the detector's over the AI's.

142 events, one issue

Grouped, counted, and still traceable

From an issue to a fix

Surfaces that share this data

Distributed Tracing

Log Management

AI & MCP Integration

E-Commerce Observability

Point OTLP at Maple.