Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

What noisy errors should Sentry filter out next? #72365

Discussion options

Not all errors are created equal - some point to critical problems in code while others are pure noise. We built Inbound Filters to automatically discard noisy errors, and hopefully make your Sentry experience more actionable.

Here's the current set of filters that Sentry provides out of the box:
Screenshot 2024年06月07日 at 5 22 13 PM

Despite our best efforts to update this list of filters when we identify new errors, we know new ones crop up all the time and our lists aren't exhaustive.

This is where we'd like to ask for your help: what other errors should Sentry be filtering out? Please be as specific as possible, and link out to examples where possible.

We'll use the ideas we crowdsource to inform our next sets of updates. Thank you!

You must be logged in to vote

Replies: 4 comments 3 replies

Comment options

We are considering a solution in the JavaScript SDK which could help detect what might be noise from browser extensions, for example, and prevent this noise from appearing in the issues feed.

getsentry/sentry-javascript#10882 (comment)

You must be logged in to vote
1 reply
Comment options

while this can be done in the JS SDK, we could also consider server side implementations which similar detects events which have these signs of being from extensions and kicking them out

Comment options

We tend to get a ton of errors from third party initializations (like ad marketplaces) that end up flooding our logs. Curious if that qualifies, or if that is already handled in a way I haven't found yet.

You must be logged in to vote
2 replies
Comment options

Yes this counts. So there are some existing ways, but they are not fool proof. The following changelog, covers some existing methods, and a new one which you can use with one of our bundler plugins.

https://sentry.io/changelog/ignore-errors-that-dont-come-from-your-code/

Comment options

I'm using allowUrls and yet I still get errors from https://www.googletagmanager.com/gtm.js.

Comment options

We see a lot of errors for chrome extensions that I swear we used to be able to detect in the stack trace, seeing chrome-extension://. Something in sentry has presumably mutated the stack traces and now replaces that with app:/// making it indistinguishable from our own errors.

Here's a line from a chrome extension: (This should be ignored, but the chrome-extension:// part has been replaced with app:/// by something in sentry)

app:///static/mainWorld/interface.js at line 1:1

Here's a line from a piwik pro analytics container (hard to act on, but shouldn't be ignored):

app:///ppms.js in m at line 38:301

Here's a line from our app code:

../../packages/shared/helpers/generic-helpers.ts in timeAsync at line 44:11

Here's a line from within next.js platform code: (Not clear why this isn't in node_modules or something, but that's likely not sentry's problem)

../../../src/client/components/use-reducer-with-devtools.ts in useUnwrapState at line 82:23
You must be logged in to vote
0 replies
Comment options

While this is not necessarily an error to filter, something that I am unable to get filtered out within the health checks is the uptime monitor from Zoraxy.

Here is a sample snippet for reference:

Screenshot 2025年01月14日 073123

image

This is on Sentry version 24.12.1 self-hosted.

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

AltStyle によって変換されたページ (->オリジナル) /