What noisy errors should Sentry filter out next?

[rachrwang]

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:

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!

[smeubank]

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)

[smeubank]

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

[collectedmind]

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.

[smeubank]

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/

[n-studio]

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

[danielbeardsley]

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

[rdevries-capland]

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:

This is on Sentry version 24.12.1 self-hosted.

[TRINNO112]

Screen.Recording.2026-09-14.214003.mp4

Some sort of weird shaking effect is there when I was trying to actually change the playback speed in the replay menu