Error grouping
Collapsing thousands of identical crashes into one issue with a counter, so a single bug means a single alert, not 5,000 emails.
See it
What it is
One bug in production does not throw once, it throws forty thousand times. Error grouping takes each incoming exception, computes a fingerprint from the exception type plus the top frames of the stack trace (and sometimes the message), and files every event with the same fingerprint into one issue with a count and a first-seen date. Sentry, Rollbar, Bugsnag, and Honeybadger all sell essentially this: turning a firehose into an inbox you can actually triage.
Reach for custom grouping rules the moment the default fingerprint misbehaves, and it will. Over-splitting happens when the message carries unique data ('User 4821 not found', 'timeout after 3021ms'), so one bug becomes thousands of issues. Over-merging happens when every error passes through the same wrapper or middleware frame, so ten unrelated bugs pile into one issue that nobody can read. Most tools let you pin grouping to specific frames, strip variable parts of the message, or set the fingerprint yourself in code.
Gotcha: minified JavaScript without uploaded source maps groups by mangled function names, and those names change on every build, so yesterday's issue resurrects as a brand new one after each deploy. Fix symbolication first, then tune fingerprints, then turn alerting back on.
Ask AI for it
Configure error grouping in this app's error tracker so duplicate exceptions collapse into one issue. Set an explicit fingerprint from the exception class plus the top three application stack frames, ignoring framework and node_modules frames. Strip variable data (IDs, timestamps, durations, URLs) out of the message before it reaches the fingerprint, and add a normalized route template as a grouping tag instead. Upload source maps at build time so frames symbolicate to stable function names. Then set alerts to fire once per new issue and once per regression, never once per event.