Issue Merging

Merge duplicate error groups to reduce noise and get accurate occurrence counts.

What Is Issue Merging?#

As your application grows, you may encounter situations where the same underlying bug produces multiple error groups. This happens when the same root cause generates slightly different stack traces, error messages, or fingerprints. Issue merging lets you combine these duplicate groups into a single, canonical issue.

Why Duplicates Happen#

Error grouping uses fingerprinting to decide which events belong together. Sometimes, the same bug produces different fingerprints:

Dynamic error messages -- "User 123 not found" and "User 456 not found" may create separate groups if the message is part of the fingerprint
Different stack frames -- the same null pointer exception hit from two different call sites
Framework internals -- different versions of a framework may wrap errors differently
Async variations -- the same error caught in a Promise .catch() vs. an async/await try-catch produces different stack traces
Minification differences -- different builds may produce slightly different minified stack traces

Without merging, you end up with fragmented data: 5 error groups that should be 1, each with partial occurrence counts and incomplete assignment history.

When to Merge#

Merge issues when:

Two or more error groups clearly represent the same underlying bug
You've confirmed the root cause is identical by examining the stack traces
The error messages differ only in dynamic values (IDs, timestamps, URLs)
The same fix would resolve all the groups

Do NOT merge when:

The errors look similar but have different root causes
The errors occur in different services or environments (handle separately)
You're unsure -- it's better to keep groups separate than to merge incorrectly

Merging in the Dashboard#

Single Merge#

Navigate to Dashboard > Error Tracking
Open the error group you want to merge into (this becomes the "primary" group)
Click the Merge button in the toolbar
Search for or select the duplicate error group(s)
Review the preview showing combined occurrence counts
Click Confirm Merge

Multi-Select Merge#

Navigate to Dashboard > Error Tracking
Check the boxes next to the error groups you want to merge
Click Merge Selected in the bulk action bar
Choose which group becomes the primary (the rest are merged into it)
Review and confirm

Choosing the Primary Group#

The primary group is the one that survives the merge. Choose it based on:

Most occurrences -- usually the primary is the group with the most events
Best title -- pick the group with the most descriptive error message
Existing assignments -- if one group is already assigned and being worked on, make it the primary

After merging, the primary group retains:

Its ID and URL
Its assignment and status
Its comments and notes
All events from both the primary and merged groups

What Happens After a Merge#

Occurrence Counts#

All events from the merged groups are attributed to the primary group. The primary group's occurrence count becomes the sum of all merged groups.

Before merge:
  Group A: 1,234 occurrences (primary)
  Group B: 567 occurrences
  Group C: 89 occurrences

After merge:
  Group A: 1,890 occurrences (includes B and C)
  Group B: redirects to Group A
  Group C: redirects to Group A

Charts and Metrics#

Historical charts (occurrences over time, affected users) are recalculated to include events from all merged groups. This gives you an accurate picture of the bug's true impact.

Assignments and Status#

The primary group's assignment and status are preserved. If the merged groups had different assignments, those are noted in the merge history but the primary's assignment takes precedence.

Links and References#

Any bookmarked URLs to merged groups redirect to the primary group
API queries for merged group IDs return the primary group
Incident and postmortem links are updated to point to the primary

New Events#

After merging, new events that match any of the merged fingerprints are attributed to the primary group. The grouping engine remembers all merged fingerprints.

Unmerging#

If you merge groups by mistake, you can undo it.

How to Unmerge#

Open the primary error group
Click Merge History in the sidebar
Find the merge you want to undo
Click Unmerge
Confirm the action

What Happens on Unmerge#

The previously merged groups are restored as separate groups
Events are redistributed back to their original groups based on fingerprint
Occurrence counts are recalculated
The primary group's count decreases to reflect only its own events
Any new events that arrived after the merge and matched a merged fingerprint are moved back to the restored group

Partial Unmerge#

If you merged groups A, B, and C, you can unmerge just B while keeping C merged into A:

Open the merge history
Select only group B for unmerging
Group B is restored; group C remains merged into A

Merge History#

Every merge and unmerge action is recorded in the merge history. View it from the primary group's detail page under the Merge History tab.

Each entry shows:

Timestamp -- when the merge/unmerge occurred
Action -- merge or unmerge
Groups involved -- which groups were merged or unmerged
Performed by -- the user who initiated the action
Occurrence impact -- how the occurrence count changed

Merge History for Group #ERR-1234

2026-03-15 14:30  MERGE   Group #ERR-1567 (567 events) merged in  by @alice
2026-03-15 14:30  MERGE   Group #ERR-1890 (89 events) merged in   by @alice
2026-03-18 09:15  UNMERGE Group #ERR-1890 (92 events) restored    by @bob

Impact on Metrics and Dashboards#

Error Rate#

After merging, the error rate for the primary group reflects the combined event stream. If Group A had 100 events/hour and Group B had 50 events/hour, the merged group shows 150 events/hour.

First Seen / Last Seen#

First seen -- the earliest timestamp across all merged groups
Last seen -- the most recent event across all merged groups

const response = await fetch('/api/dashboard/error-groups/merge', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    primaryGroupId: 'err_abc123',
    mergeGroupIds: ['err_def456', 'err_ghi789'],
  }),
});

const result = await response.json();
// {
//   primaryGroup: {
//     id: 'err_abc123',
//     occurrenceCount: 1890,
//     mergedGroups: ['err_def456', 'err_ghi789'],
//   }
// }

Unmerge Groups#

const response = await fetch('/api/dashboard/error-groups/unmerge', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    primaryGroupId: 'err_abc123',
    unmergeGroupIds: ['err_ghi789'],
  }),
});

Get Merge History#

const response = await fetch('/api/dashboard/error-groups/err_abc123/merge-history');
const history = await response.json();
// {
//   entries: [
//     {
//       action: 'merge',
//       groupId: 'err_def456',
//       occurrences: 567,
//       performedBy: 'user_alice',
//       timestamp: '2026-03-15T14:30:00Z',
//     },
//   ]
// }

Best Practices#

Before Merging#

Inspect stack traces -- confirm the root cause is truly the same
Check environments -- don't merge production and staging errors
Check services -- errors from different services may look similar but have different causes

Merge Workflow#

Use the search/filter to find potential duplicates (same error type, similar message)
Open each candidate in a new tab and compare stack traces
If confirmed as duplicates, merge into the group with the most context (most occurrences, existing assignment, comments)
Add a comment to the merged group explaining why you merged them

Ongoing Maintenance#

Review the error group list periodically for new duplicates
After deploying a fix, check if the fix resolves all merged fingerprints
If a merged group keeps growing after a fix, some of the merged fingerprints may represent a different bug -- unmerge and investigate