Inbound Filters

Sentry provides several methods to filter data in your

projectRepresents your service in Sentry and allows you to scope events to a distinct application.
. 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

quotaThe monthly number of events that you pay Sentry to track.
, 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
  • React hydration errors
  • Transactions coming from healthcheck and ping requests

Transactions coming from healthcheck

In essence, the health check filter serves the purpose of excluding transactions that are generated as a part of health check procedures.

By applying this filter, you effectively bypass transactions that, while crucial for app stability assessment, hold limited value for you beyond their designated function.

We consider a transaction to be a health check if its name matches one of the following glob patterns:

  • *healthcheck*
  • *healthy*
  • *live*
  • *ready*
  • *heartbeat*
  • */health
  • */healthz
  • */ping

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 Custom 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.


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]
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").
Suggest an edit to this page   |  Contribute to Docs   |  

Report a Problem

🎉 Thank you for your feedback! 🙌
Report a problem