Error Grouping
How ErrTap groups events into issues using fingerprints, and how to control grouping, statuses, and severity.
How events become issues
Events become issues by fingerprint. By default ErrTap normalizes each error — addresses, UUIDs, numbers, and string literals are masked — then hashes the error type plus the top stack frames. This means user 41 not found and user 87 not found group together into one issue.
Fingerprinting
When the default grouping gets it wrong, pass a fingerprint from any SDK to take control:
captureException(e, { fingerprint: 'checkout-payment-failure' });Same key → one issue, regardless of message or stack. Different keys → separate issues.
Issue statuses
| Status | Meaning |
|---|---|
open | Active — new events are arriving |
resolved | Marked resolved; will reopen as a regression if the same error appears in a new release |
ignored | Suppressed — events still ingest but the issue won't alert or surface in the default view |
snoozed | Temporarily silenced until the snooze window expires or a new event arrives |
Severity levels
Events carry a level field:
| Level | Description |
|---|---|
error | Default — a caught or uncaught exception |
warning | Degraded behaviour, non-fatal |
info | Informational; used with captureMessage |
Severity is passed at capture time:
captureMessage('payment fallback used', { level: 'warning' });Issues inherit the highest severity level seen across their events.