Sentry’s job is to tell you when your app breaks. To do that, we group individual errors into issues. First by fingerprinting, which lexically matches errors based on their structure, then by an AI fallback: when fingerprinting can’t find a match, an ML model compares the new error’s stacktrace against existing issues and merges it if they’re semantically similar. We recently upgraded the model, preventing 20% more duplicate issues from being created while halving the rate of incorrect merges.
What makes grouping hard
We talked about v1 of AI grouping in Using a transformer-based text embeddings model to reduce Sentry alerts by 40% and cut through noise.
A good grouping algorithm minimizes both undergrouping and overgrouping. Minimizing undergrouping means Sentry isn’t spamming your feed with new issues for the same underlying problem. Minimizing overgrouping means Sentry always tells you about new categories of errors your app is experiencing. Striking the right balance between these can be tricky and subjective.
Overgrouping is arguably the more sinister failure mode. When Sentry incorrectly merges an error into an issue, we’re hiding a problem that should be addressed by a different work stream; this error may have a different priority, root cause, and fix.
