Inbound Filters

Sentry provides several methods to filter data in your project. Using sentry.io 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

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.

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*. The wildcard matcher can be used at the beginning or end of the string.
• On message events, the filter matches the fully formatted message.
• Transactions are never matched by this filter.

To ensure you’re adding the correct message to the inbound filter setting, check the JSON for an event in the issue. The filter by error message setting matches the data found in the "title" field near the end of the file.

Releases

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.
• Globbing 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.
• ! works for negation, but only within brackets, such as in [!1-4] to match any character that is not [1-4].

Generally, bash's out-of-the-box behavior for globbing is close to what Sentry supports:

touch 1.2.3
touch 1.2.4
echo 1.2.*
echo 1.2.[!3]