# 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.

## 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.

- **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

## From an issue to a fix

### fingerprint — 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.

### exception.stacktrace — 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.

### first seen — 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.

### claim — 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.

### set severity — 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.

## Related

- [Distributed Tracing](https://maple.dev/features/distributed-tracing.md)
- [Alerting](https://maple.dev/features/alerts.md)
- [AI & MCP Integration](https://maple.dev/features/ai-mcp-integration.md)
- [E-Commerce Observability](https://maple.dev/use-cases/ecommerce-observability.md)