Inbound Filters

Sentry provides several methods to filter data in your project. Using to filter events is a simple method since you don't have to configure and deploy your SDK to filter projects.

Inbound Data Filters

Inbound data filters allow you to determine which errors, if any, Sentry should ignore. Explore these by navigating to [Project] > Project Settings > Inbound Filters.

These filters are exclusively applied at ingest time and not later in processing. This, for instance, lets you discard an error by error message when the error is ingested through the JSON API. On the other hand, this filter doesn't apply to ingested minidumps. Filtered events do not consume quota, as discussed in What Counts Toward My Quota.

Inbound filters include:

  • Common browser extension errors
  • Events coming from localhost
  • Known legacy browsers errors
  • Known web crawlers
  • By their error message
  • From specific release versions of your code
  • From certain IP addresses

Once applied, you can track the filtered events (numbers and cause) using the graph provided at the top of the Inbound Data Filters view.

builtin inbound filters

How Filtering Works

Inbound data filters are not case sensitive.

Error Message

To use inbound data filters for error messages, keep the following in mind:

  • You can provide multiple patterns, one per line. The filter applies if any of the patterns match.
  • On error events, the filter matches the entire error description in the format {exception.type}: {exception.value}. We do not recommend matching the full error description including the colon, and suggest you match with wildcards. For example, to match any "ConnectionError", use the filter *ConnectionError*.
  • On message events, the filter matches the fully formatted message.
  • Transactions are never matched by this filter.


To filter releases, keep the following in mind:

  • The filter matches the full release name provided during SDK initialization. If you provide the recommended package prefix, the release is in the format package@version, for example: my-example@1.4.0-beta.1.
  • Regular glob rules apply and there is no special casing for SemVer. This allows for matching prefixes, such as my-example@1.*.
  • The filter never applies to events without a release.

Glob Matching

The error messages and releases filters use glob patterns. Globs are case insensitive and allow you to specify wildcards to match variable input. For example, *panic* matches any error that contains the words "panic", "PANIC" or "PaNiC".

Some symbols, such as the * character, receive special meaning as meta characters. To match a literal asterisk, escape it with a backslash: \*. Inbound data filters use the following meta characters:

  • ? matches any single character.
  • * matches zero or more characters.
  • \ escapes the next character making it literal. If it precedes a non-meta character, the backslash is ignored.
  • [, ], {, and } are reserved meta characters.
Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").