Issue grouping and reversible merges

Open Errors → Grouping in the application and environment you want to change. The page keeps issue merges, undo history and future grouping rules together. Existing event IDs, payloads, captured frames, source-map inputs, sessions, traces and releases are preserved.

Merge and undo

Find the source and destination independently by title. Each selector shows up to 100 matching current issues. Preview merge computes retained event counts and distinct captured affected actors, including overlap between the two groups. Review the destination, provide a reason, and choose Merge into destination.

The destination keeps its status and assignment. Merging does not represent a new failure and does not send an alert. New occurrences of the source fingerprint route to the destination and follow its ordinary regression/snooze behavior. Source issue URLs follow the destination; links that identify an exact event ID and timestamp follow that occurrence’s actual current issue. Feedback uses that same accepted occurrence when resolving its issue.

Each merge records its original issue membership, source triage state, order and audit event. Merge history → Review undo restores that membership, including new occurrences received while merged. The source’s former triage state is restored; a retained new failure can regress a previously resolved source or an expired snooze. A former assignee is restored only while active, still an organization member and allowed to read Errors; a deleted resolver is cleared. The destination keeps its current triage. Undo uses recorded assignment revisions, independently of caller timestamps.

Undo newer related merges first. For example, after merging A into B and then B into C, undo B→C before A→B. History is paginated, with 100 operations per page. Concurrent changes are serialized and stale grouping revisions are rejected. Undo refuses unavailable original state. It cannot recover expired or otherwise deleted payloads.

Rules and precedence

Enabled rules run from top to bottom; the first rule whose conditions all match wins. It overrides the SDK’s fingerprint for that future occurrence. Without a match, an explicit SDK fingerprint wins, followed by the existing normalized default algorithm.

A rule has one to four conditions. Available inputs are:

• Error name: the captured exception name, trimmed; missing names use Error.
• Normalized file: the first relevant captured frame’s basename, with query/fragment, source location and build hash removed.
• Normalized function: the first relevant captured frame’s function after standard wrapper prefixes are removed.
• Level: fatal, error, warning or info.

Equals and starts-with are case-sensitive. Conditions do not execute regex or scripts and cannot inspect messages, identities or request data. File/function selection uses the first in-app frame where available, otherwise the first relevant captured frame. Missing file/function values use the anonymous marker. Source-map resolution happens later and never rewrites these grouping inputs.

Choose one issue for all matching events, or separate issues by error name, normalized file or normalized function. A rule’s stable ID retains its fingerprint buckets across edits. Removing and recreating a rule makes new buckets. Manual merges still apply to any resulting fingerprint bucket.

Preview grouping rules uses the newest 500 retained occurrences from at most seven days. It shows sampled current issues, proposed fingerprint groups, and up to fifty groups with their first matching rule. The sample may be incomplete and is not a forecast. Saving applies only to future accepted occurrences; it does not move historical events. Preview again after each edit before saving.

Occurrence details show the original SDK/default fingerprint, original issue and captured policy revision. Operators with People PII access can inspect the actual rule conditions from that revision, even after the current rule changes. Older legacy events identify SDK/default grouping when no rule provenance was captured.

Permissions and privacy

Errors read opens the page. Merges and undo require Errors write; viewing/editing rule conditions and previews additionally requires People PII. Every mutation uses the console’s membership, same-origin, CSRF and passkey checks. A passkey verified within ten minutes and a reason are required.

Audit events identify the operation, scope, revision, member count and a configuration digest. They do not copy raw event content, captured actor keys or rule predicate values. Reasons stay in the audit ledger, so avoid personal details there. Rule conditions and captured evidence keep their normal private permission boundaries. Grouping rules are never exposed through public ingest or SDK configuration.

Counts, retention and limits

Merge, undo and maintenance recompute counts from retained occurrences: event count, distinct captured affected actors, UTC daily series, first/last timestamps, chronological releases and severity. The actor chosen at capture prefers resolved person, then distinct ID, anonymous ID, session ID and hashed IP. It is a telemetry identity, not proof of a person. Captured actor keys are not rewritten by later identity changes.

Ingest updates counters immediately. Expiry between maintenance passes can leave older counters until the worker next visits that issue. A group whose events have all expired keeps zero counts while an active merge still needs its fingerprint mapping. An active mapping is deliberate operator state and remains reversible without recovering deleted payloads.

• At most 20 rules, with 4 conditions each.
• Interactive merge: 100 original issues and 100,000 stored events per combined group.
• Undo has no event-count refusal when a group grows. Operations remain atomic under a 12-second statement deadline; a timeout leaves the prior grouping intact.
• Per environment: 1,000 retained merge records and 1,000 policy versions.
• The hourly counter worker and daily purge visit 100 least-maintained environments, then 100 least-maintained issues per environment. Purge removes up to 5,000 expired events per environment/pass. The worker must run for physical cleanup.

Undone merge records and unreferenced old policy versions expire after application retention, capped at ninety days. Active merge records, the current policy, and versions still referenced by stored occurrences remain. Audit history persists. Application/organization deletion cascades through the grouping configuration and history tables.