Skip to main content
The Event Filters integration (formerly inboundFiltersIntegration) filters out events based on error messages, URLs, and transaction names. It includes a curated list of common browser errors that are typically not actionable.

Installation

This integration is enabled by default in all Sentry SDKs.

Configuration

Ignore Errors by Pattern

Filter out errors matching specific patterns:

Filter by URL

Control which errors are captured based on the script URL:

Ignore Transactions

Filter out performance transactions by name:

Integration Options

Configure the integration directly for more control:

Options Reference

Array<string | RegExp>
Error messages or patterns to ignore
Array<string | RegExp>
URLs to block errors from
Array<string | RegExp>
Only capture errors from these URLs (if specified)
Array<string | RegExp>
Transaction names to ignore
boolean
default:"false"
Disable the default list of ignored errors

Default Ignored Errors

The integration includes these patterns by default:
These errors are typically:
  • Browser extension conflicts
  • CORS/cross-origin script errors
  • Third-party script issues
  • Non-actionable browser warnings

How It Works

The integration processes events in this order:
1

Check Error Patterns

Compare error messages against ignoreErrors patterns
2

Validate Error Content

Drop events without meaningful error data (no message, type, or stacktrace)
3

Check Deny URLs

Filter errors from scripts matching denyUrls
4

Check Allow URLs

If allowUrls is set, only keep errors from matching URLs
5

Check Transaction Names

Filter transactions matching ignoreTransactions patterns

Source Code

The Event Filters integration is implemented in: packages/core/src/integrations/eventFilters.ts:52

Common Use Cases

Ignore Third-Party Errors

Ignore Health Check Endpoints

Custom Error Filtering

Best Practices

Be careful not to filter too aggressively. You might miss important errors.
  • Review filtered errors periodically to ensure you’re not missing issues
  • Use specific patterns rather than broad filters
  • Consider using beforeSend for complex filtering logic
  • Monitor your error volume to detect over-filtering