Users hit errors you never see, and you’re wondering what is exception tracking. It captures each error from your running app, groups repeats into one issue, and keeps the stack trace for you to fix.
This guide is part of the wider topic of error monitoring, and it stays on the exception side of the story.
| Item | Value |
|---|---|
| Better Stack grouping presets | 3 presets |
| Better Stack: digits masked in messages | numbers with 4 or more digits |
| Better Stack: hex strings masked in messages | 8 or more characters |
| PostHog grouping logic order | 3 levels: client-side fingerprint, grouping rules, automatic fingerprinting |
| PostHog issue name and description limit | 255 characters each |
The figures come from the documentation of Better Stack and PostHog, two error tracking products named here as neutral examples. Vendors change their defaults and limits, so check the source before you rely on them.
How an exception becomes an issue
An exception is an error your running code raises, and exception tracking collects each one automatically instead of waiting for a user to report it. Tideways, for example, describes its tracker as detecting PHP fatal errors and exceptions and then aggregating them, with error details that include the message, stacktrace, and context information, according to its documentation.
Most tools follow the same loop:
- Capture: an SDK or agent inside your app sends each exception with its message and stack trace.
- Enrich: context such as tags, affected users or the release is attached to the event.
- Group: similar events are merged into a single issue.
- Notify: new, re-opened or regressed issues alert the people who can fix them.
- Triage: someone resolves, ignores or reopens the issue as work progresses.
The grouping step is where most of the value sits, because it turns a flood of raw events into a short list you can actually work through.
How grouping turns many errors into one issue
Without grouping, one bug hit by many users would produce many separate alerts. PostHog’s documentation puts the idea simply: issues are created by grouping together similar exception events, as its grouping guide explains.
Better Stack says errors are automatically grouped based on their stack trace and other identifying characteristics. Each group then shows its occurrences, affected users and a trend chart, according to its exception grouping page.
Tideways groups by where in the code an error occurs, using a fingerprint. For exceptions and fatal errors that fingerprint is built from the exception class name plus the class and function names in every frame of the stack trace, and all errors with the same fingerprint are grouped together, as the Tideways docs describe.
Why messages are cleaned before grouping
Two errors can be the same bug yet carry different text, such as a different user ID. Better Stack’s presets normalize the message before grouping: UUIDs, hex strings with 8 or more characters, e-mail addresses, IP addresses, and numbers with 4 or more digits are replaced with a *, per its documentation.
That is why “user not found” errors for different accounts can end up in one group instead of dozens.
Choosing a grouping strategy
Better Stack offers three presets, and the first is its default:
- Error name and call stack: groups by the call stack hash and error type, using the normalized message only as a fallback when there is no call stack.
- Call stack: uses the call stack hash alone.
- Error name: combines the error’s type and normalized message.
Most teams never need to leave the default. The presets exist for cases where the default merges too much or too little.
What each issue should tell you
A good tracker gives you enough context to decide whether to act without opening five other tools. Look for these details on every issue:
- The error message and a stack trace showing where it was triggered.
- How many times it happened, and when it was first and last seen. Tideways counts occurrences over all time and since the last release, as its documentation states.
- Which users were affected, so you can judge impact.
- Tags and metadata extracted from the error.
- Session replays linked to the captured error, where the tool supports them. Better Stack lists this on its grouping page.
Issues also carry a status. In Better Stack you can resolve an error once you have addressed it, ignore errors you do not need to see, and unresolve one that reoccurs.
How releases and notifications fit in
Tracking becomes more useful once it knows about your releases. Tideways says that when combined with releases, the occurrences since the last release are reset to zero, so you can see whether a deploy fixed or reintroduced a problem, per its error tracking documentation.
Notifications work the same way. Tideways sends alerts about errors that are new, re-opened or re-appeared after a release, and supports email, Slack, Microsoft Teams and webhooks, as stated on its error tracking feature page.
If you want the practical steps, the guide on how to set up error alerts covers them.
Is exception tracking the same as logging?
They overlap, but they do different jobs. A log is a stream of lines you search, while a tracker turns errors into grouped issues with counts, affected users and a status you can work through.
A separate comparison of error monitoring vs logging goes deeper into when you need one, the other, or both.
Grouping mistakes to avoid
Automatic grouping is a good starting point, but it is not perfect, and overriding it can backfire. PostHog states that every issue is meant to represent a single problem that can be fixed by a single change, and that over-grouping makes issues meaningless, in its grouping guide.
Watch for these pitfalls:
- Grouping too early. PostHog advises custom grouping only when the default algorithm is creating a lot of noise.
- Catch-all rules first. Rules are evaluated in order, so a catch-all rule at the top will always match and block the others.
- Using grouping as a filter. Problems that assignment rules or custom property filters can solve should not be handled by grouping.
- Forgetting overrides exist. A client-side fingerprint wins over rules and automatic logic in PostHog, and a fingerprint array overrides the calculated grouping in Better Stack.
- Leaving duplicates split. Issues describing the same problem can be merged, and the merged issue receives all events and aggregated counts.
When in doubt, start with the default and adjust only after you see real noise in your issue list.
Frequently asked questions
What is exception tracking in simple terms?
Show answer
It is a way to automatically collect the errors your application raises, group the repeats into issues, and give you the stack trace and context needed to fix them.
What is a fingerprint?
Show answer
A fingerprint is the value used to decide which errors belong together. In Tideways, for exceptions and fatal errors it is based on the exception class name and the class and function names in the stack trace frames, and errors sharing a fingerprint are grouped, per its documentation.
Do I need custom grouping rules?
Show answer
Usually not. PostHog’s guide recommends custom grouping only when the default algorithm creates a lot of noise.
What happens when a fixed error comes back?
Show answer
You can reopen it. Better Stack lets you unresolve an error that reoccurs, and Tideways resets counts per release and triggers its new-exception notifications again when the error is seen after a release, according to the Tideways feature page.
