Grouping operations

Grouping decides which occurrences are triaged together. Good grouping keeps duplicate work low while preserving meaningful differences in owner, fix, and customer impact.

Why grouping matters

A group should represent one practical root cause. If unrelated failures share a group, responders lose context. If one failure is split across many groups, teammates duplicate investigation and issue tracking.

Review fingerprints

Fingerprint details explain why Errorgap grouped occurrences together. Review the message, error type, top frames, function names, and normalized context before changing grouping.

Merge groups

Merge groups when they share the same practical fix and should move through triage together.

• Confirm the stack traces point to the same failing code path.
• Check that environments and releases do not imply different ownership.
• Review linked issues so the merged group does not hide active work.
• After merging, keep one clear owner and issue link.

Split groups

Split a group when it contains occurrences with different causes, fixes, owners, or impact. Use split previews to check the proposed result before changing active triage state.

Use similar groups

Similar groups are suggestions, not decisions. Use them during triage to spot duplicates, regressions, or related failures that should be mentioned in the same incident.

After a grouping change

• Recheck state, assignee, and linked issues.
• Update incident evidence if the group belongs to active response.
• Watch the next occurrences to confirm the grouping now matches reality.