An error tracker that alerts on everything gets muted: tune grouping and alert rules

How events become issues

An error tracker does not show you every event as its own line. It groups events into issues, and the grouping decides how many things you appear to have to fix. Sentry gives each event a fingerprint, using the stack trace, the exception type and the message, and puts events with matching fingerprints in one issue. You can see an event's fingerprint in its JSON: the value default means the built-in grouping was used and anything else is a custom value. If you see a hundred issues for what seems to be one fault, or one issue that hides two different faults, grouping is the first thing to check.

• Open two issues you think are the same fault and compare their stack traces, messages and fingerprints.
• Open one issue you think hides two faults and look at the range of messages and traces inside it.

Why one fault becomes many issues, or the reverse

The documentation explains that alike-looking issues stay separate because of some difference, such as the function name at the top of the stack, or frames from middleware, a library or the framework that make two identical paths differ. A broad fingerprint rule can do the opposite, putting events with different stack traces into one issue. The tools to change this are merging existing issues, which can be undone from the merged issues tab, fingerprint rules, stack trace rules that control which frames count, and fingerprints set in the SDK. Rules and SDK fingerprints affect only events that arrive afterwards. Use merging for the issues you already have, and rules for the future.

• Merge duplicates first and then add a rule only if the same split keeps recurring.
• Write down what each rule is meant to merge, so a later reader can tell if it is too broad.

Design one alert that someone will read

Sentry's alerts are built from issue sources, event triggers, filters, actions and throttling. Example triggers are a new issue, an issue that escalates and a resolved issue that comes back. Actions can notify a person, open a ticket or call a webhook, and the documentation gives Slack and Jira as examples. Its guidance is to use filters so that only the issues that matter to your team notify, and to choose a channel arrangement that matches how your team triages, whether per service or one catch-all. Start with one rule for new issues in the production environment, routed to the one channel the team actually watches, and widen it only when that rule is trusted.

• Decide who is expected to look at the channel, and what they should do with a notification.
• Send a test error and check that the notification arrives and that a repeat of the same error does not add a second issue.

Releases, regressions and how the paid job is accepted

If events from a newer release arrive for an issue that was marked resolved, Sentry flags a regression, which only works if events carry a release. The error-tracking setup job creates one alert rule for new issues, tests it with a deliberate error and records the rule in the settings summary so you can narrow or widen it. It does not triage the errors that arrive afterwards, tune thresholds over time or decide who responds, and it makes no promise about response time or about catching every error. Those are your decisions, and further work is a separate scope. Start an enquiry with the channel you use and the condition you want to hear about; send no tokens or event data.