--- title: "Inbound Filters" description: "Learn about the different methods for filtering data in your project." url: https://docs.sentry.io/concepts/data-management/filtering/ --- # Inbound Filters | Sentry Docs 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](https://docs.sentry.io/platform-redirect.md?next=/configuration/filtering/). ## [Inbound Data Filters](https://docs.sentry.io/concepts/data-management/filtering.md#inbound-data-filters) Inbound data filters allow you to determine which errors, if any, Sentry should ignore. Explore these by navigating to [**Project Settings > Inbound Filters**](https://sentry.io/orgredirect/organizations/:orgslug/settings/projects/:projectId/filters/data-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](https://docs.sentry.io/pricing/quotas.md#what-counts-toward-my-quota-an-overview). Inbound filters include: * Common browser extension errors * Transactions coming from health checks and ping requests * Events coming from legacy browsers * Events coming from localhost * Errors from known web crawlers * React hydration errors * ChunkLoadErrors * Events from certain IP addresses * Events with certain error messages * Events from specific release versions of your code * Events from non-allowed domains (origin-based; see [Allowed Domains](https://docs.sentry.io/concepts/data-management/filtering.md#allowed-domains)) * [Custom filters](https://docs.sentry.io/concepts/data-management/filtering.md#custom-filters) on different data types that allow combinations of different attributes ### [Legacy Browser Filters](https://docs.sentry.io/concepts/data-management/filtering.md#legacy-browser-filters) The legacy browser filters allow you to filter out certain legacy versions of browsers that are known to cause problems. Legacy browser filters were updated in December 2025 and will be periodically evaluated to include additional legacy versions. If you had a legacy browser filter on before the update, the old filter will appear in your settings as "Deprecated". Deprecated legacy browser filters still work. However, if you turn them off, you won't be able to turn them on again and will need to use the new filters instead. ### [Browser Extension Errors](https://docs.sentry.io/concepts/data-management/filtering.md#browser-extension-errors) Some browser extensions are known to cause errors. You can filter these out using the browser extension filter, which checks the error message and event source to see if it's a known error coming from a browser extension. To see the full list of errors filtered out by the browser extension filter, see the [source code in relay](https://github.com/getsentry/relay/blob/master/relay-filter/src/browser_extensions.rs#L9-L76). ### [Web Crawler Errors](https://docs.sentry.io/concepts/data-management/filtering.md#web-crawler-errors) Due to their nature, web crawlers often encounter errors that normal users won't see. You can use the web crawler filter to filter out errors from web crawlers, determined by the event's user-agent, from the following sites: Baidu, Yahoo, Sogou, Facebook, Alexa, Slack, Google Indexing, Pingdom, Lytics, AWS Security Scanner, Hubspot, Bytedance, and other generic bots and spiders. Errors from Slack's Slackbot web crawler will not be filtered. ### [IP Addresses](https://docs.sentry.io/concepts/data-management/filtering.md#ip-addresses) Filters events based on the **originating IP address of the client making the request**, not the user IP contained within the user data inside the request. This ensures that filtering decisions rely on the actual source of the request, as determined by network-level information, rather than data provided in the event payload. Sentry attempts to identify the request's origin using the **forwarded IP address**. If no forwarded IP is available, it falls back to the **direct IP** of the client connecting to Sentry's servers. The supported IP address formats are: * **IPv4 Addresses**: Standard dotted-decimal notation (e.g., 1.2.3.4, 122.33.230.14, 127.0.0.1). * **IPv6 Addresses**: Standard colon-separated hexadecimal notation (e.g., aaaa:bbbb::cccc, a:b:c::1). * **IPv4 Network Ranges (CIDR Notation)**: IPv4 address with a subnet mask (e.g., 122.33.230.0/30, 127.0.0.0/8). * **IPv6 Network Ranges (CIDR Notation)**: IPv6 address with a subnet mask (e.g., a:b:c::0/126). ### [Allowed Domains](https://docs.sentry.io/concepts/data-management/filtering.md#allowed-domains) Sentry checks the `Origin` or `Referer` HTTP header of each inbound request against your project's allowed domain list. Requests from unrecognized origins are rejected and appear as **Disallowed Domain** in your [Stats](https://docs.sentry.io/product/stats.md). This filter only applies to requests that include an `Origin` or `Referer` header. Requests without one — common for server-side SDKs and direct API submissions — are always accepted, even when an allowed domain list is configured. To restrict server-side ingestion, use a [project rate limit](https://docs.sentry.io/pricing/quotas.md#rate-limits) or an allowlist at the network level. ### [Transactions Coming from Health Check](https://docs.sentry.io/concepts/data-management/filtering.md#transactions-coming-from-health-check) 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*` * `*health-check*` * `*heartbeat*` * `*/health` * `*/healthy` * `*/healthz` * `*/_health` * `*/[_health]` * `*/live` * `*/livez` * `*/ready` * `*/readyz` * `*/ping` * `*/up` ## [Session Replay Filtering](https://docs.sentry.io/concepts/data-management/filtering.md#session-replay-filtering) Inbound data filters have partial support for [Session Replay](https://docs.sentry.io/product/session-replay.md). Only a subset of the available inbound filters apply to Session Replays. The following inbound filters **do** apply to Session Replays: * **IP Addresses** - Filters replays based on the originating IP address * **Releases** - Filters replays from specific release versions * **Request URLs** - Filters replays based on the URL where the replay was captured * **User-Agents** - Filters replays based on the browser's user-agent string The following inbound filters **do not** apply to Session Replays: * Error messages * Browser extension errors * Web crawler errors * Legacy browser filters * React hydration errors * ChunkLoadErrors * Health check transactions **Note**: Because filtered outcomes are emitted per **segment** whereas successful outcomes are emitted per **replay** (a replay being a collection of segments), you may see a noticeable increase in filtered outcomes on your [Stats](https://sentry.io/orgredirect/organizations/:orgslug/stats) page when Session Replay filtering is active. This is expected behavior and not an error. *** ##### Note Error messages from minidumps do not yet apply. Once applied, you can track the filtered events (numbers and cause) using the graph provided at the top of the Inbound Data Filters view. ## [Logs Filtering](https://docs.sentry.io/concepts/data-management/filtering.md#logs-filtering) Inbound data filters have partial support for [Logs](https://docs.sentry.io/product/logs.md). Only a subset of the available inbound filters apply to Logs. The following inbound filters **do** apply to Logs: * **Log Message** - Filters logs based on the log message match * **Releases** - Filters logs from specific release versions The following inbound filters **do not** apply to Logs: * Error messages * Browser extension errors * Web crawler errors * Legacy browser filters * React hydration errors * ChunkLoadErrors * Health check transactions * IP Address * Request URLs * User-Agents A [custom filter](https://docs.sentry.io/concepts/data-management/filtering.md#custom-filters) on the **Logs** data type drops logs by log message, release, or IP address. ## [Application Metrics Filtering](https://docs.sentry.io/concepts/data-management/filtering.md#application-metrics-filtering) Inbound data filters have partial support for [Application Metrics](https://docs.sentry.io/product/metrics.md). The following inbound filters **do** apply to Application Metrics: * **Application Metrics** - Filters Application Metrics by metric name (supports glob pattern matching, for example `my_metric.*`) * **Releases** - Filters Application Metrics from specific release versions A [custom filter](https://docs.sentry.io/concepts/data-management/filtering.md#custom-filters) on the **Metrics** data type drops Application Metrics by metric name, release, or IP address. ## [Custom Filters](https://docs.sentry.io/concepts/data-management/filtering.md#custom-filters) This feature is available only if your organization is on [a Trial, Business, or Enterprise plan](https://sentry.io/pricing/). This feature is available only if you're in the [Early Adopter program](https://docs.sentry.io/organization/early-adopter-features.md). Features available to Early Adopters are still in-progress and may have bugs. We recognize the irony. A custom filter drops data that matches all of its conditions. Use it for noise the built-in filters do not cover, such as a flaky error message, traffic from one IP range, or logs from an old release. Like every inbound filter, a custom filter runs at ingest time, and filtered data does not count toward your quota. Create and manage custom filters under **Custom Inbound Filters** in [**Project Settings > Inbound Filters**](https://sentry.io/orgredirect/organizations/:orgslug/settings/projects/:projectId/filters/data-filters/), or with the [API](https://docs.sentry.io/concepts/data-management/filtering.md#custom-filter-api). A filter has: * A **name** that identifies it in the table and in its statistics. * A **data type** that specifies which data will be filtered. * One or more **conditions**. The conditions under which data will be dropped. * An **active** toggle. A project can have up to 50 custom filters. If your organization leaves a plan that includes custom filters, Sentry keeps the filters but stops applying them until you upgrade again. ### [Data Types](https://docs.sentry.io/concepts/data-management/filtering.md#data-types) | Data type | What the filter inspects | | -------------- | ---------------------------------------------------------------- | | Errors | Error and message events | | Logs | [Logs](https://docs.sentry.io/product/logs.md) | | Metrics | [Application Metrics](https://docs.sentry.io/product/metrics.md) | | Spans | Spans | | All Data Types | All the above | ### [Conditions](https://docs.sentry.io/concepts/data-management/filtering.md#conditions) Conditions specify which data will be matched and therefore discarded. Each condition consists of a property, an operator and one or more values. When there are multiple conditions, they will be combined using logical `AND`. When a condition gets a list of values, it will match any of the values in the list. | Property | Key | Data types | Matches | | ------------- | ------------------ | ---------- | ---------------------------------------------------------------- | | Error Message | `error_message` | Errors | The error message of the event | | Error Type | `error_type` | Errors | The exception type alone, such as `TypeError` | | Country | `geo_country_code` | Errors | The two-letter country code of the user's location, such as `US` | | Log Message | `log_message` | Logs | The body of the log | | Metric Name | `metric_name` | Metrics | The name of the metric, such as `checkout.total` | | Release | `release` | All | The release the data was sent from | | IP Address | `ip_address` | All | The IP address the data was sent from | Filters may consist of at most 10 conditions or 4000 characters when sent to the API endpoint. #### [Operators](https://docs.sentry.io/concepts/data-management/filtering.md#operators) Type `key:value` for a plain match, or pick another operator from the menu of the term. | Operator | In the API | Properties | Matches when | | -------------------------------------------------------- | -------------------------------------------------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | is (`key:value`) | `equals`, or wildcard matching when the value contains `*` | Text properties, Release | The property equals the value or the value with the wildcard | | contains, starts with, ends with | `contains`, `starts_with`, `ends_with` | Text properties, Release | The property contains, starts with, or ends with the value | | does not contain, does not start with, does not end with | `does_not_contain`, `does_not_start_with`, `does_not_end_with` | Text properties, Release | No value matches | | `>`, `>=`, `<`, `<=` | `gt`, `gte`, `lt`, `lte` | Release | The [version](https://docs.sentry.io/concepts/data-management/filtering.md#release) of the release compares as given. Takes one value | | matches | `cidr` | IP Address | The address is one of the values, or inside one of the ranges | | does not match | `not_cidr` | IP Address | The address is outside every value | A value with `*` follows the [glob matching](https://docs.sentry.io/concepts/data-management/filtering.md#glob-matching) rules. Text comparisons are not case-sensitive. A negated operator also matches data that has no value for the property. For example, a Release condition with the `does not contain` operator and the value `beta` also drops data that was sent without a release. #### [Error Message](https://docs.sentry.io/concepts/data-management/filtering.md#error-message) * The condition checks the exception type, the exception value, and the message of the event separately. For example, to drop any "ConnectionError", use `error_message:*ConnectionError*`. To find the text to match, open the JSON of an event in the issue. The condition matches the data found in the `exception` values and in the `logentry` field. ##### Note Matching on the deobfuscated `{exception.type}` is not supported for [ProGuard](https://docs.sentry.io/platform-redirect.md?next=%2Fenhance-errors%2Fproguard%2F) events, because deobfuscation of class names happens after ingestion. See [Troubleshooting](https://docs.sentry.io/concepts/data-management/filtering.md#error-message-filters-do-not-match-deobfuscated-exception-types). #### [Error Type](https://docs.sentry.io/concepts/data-management/filtering.md#error-type) The condition checks the exception type alone. An event with several chained exceptions matches when any of their types matches. Use it to narrow a filter to one type without also matching events that only mention that type in their message. For example, `error_type:TypeError error_message:*undefined*` drops only the `TypeError` events whose message mentions "undefined". #### [Country](https://docs.sentry.io/concepts/data-management/filtering.md#country) The condition matches the two-letter country code of the user's location, such as `US`. Sentry derives the location from the IP address the event was sent from, unless the SDK sets `user.geo.country_code` on the event. For example, `geo_country_code:[CN,RU]` drops errors from users in China or Russia. #### [Release](https://docs.sentry.io/concepts/data-management/filtering.md#release) * The condition 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`. On logs, metrics, and spans, the condition reads the `sentry.release` attribute. * The `is`, `contains`, `starts with`, and `ends with` operators treat the release as text. There is no special casing for SemVer. This allows for matching prefixes, such as `release:my-example@1.*`. * The `>`, `>=`, `<`, and `<=` operators compare the release as a version, so `release:<2.0.0` drops data from every release before 2.0.0. Two conditions express a range: `release:>=2.0.0 release:<4.0.0`. * The condition never matches data without a release, except under a negated operator. A version comparison follows these rules: * The value is one release with a version, such as `1.2.0` or `myapp@1.2.0`. Sentry rejects a value without a version, such as a commit hash. * A version has one to four numeric parts. Missing parts count as zero, so `1.2` equals `1.2.0`. * A pre-release sorts below its final release, so `1.0.0-rc.1` is less than `1.0.0`. The build code, such as `+build.2`, is ignored. * A value with a package only matches releases of that package. A value without a package compares with releases of every package. * A release without a version, such as a commit hash, never matches a comparison. #### [Log Message](https://docs.sentry.io/concepts/data-management/filtering.md#log-message) The condition matches the body of the log. Match with wildcards instead of the full message. For example, to drop any "Connection timeout asbq33q", use `log_message:*Connection timeout*`. #### [Metric Name](https://docs.sentry.io/concepts/data-management/filtering.md#metric-name) The condition matches the name of the metric. For example, to drop all metrics under the `my_metric` namespace, use `metric_name:my_metric.*`. #### [IP Address](https://docs.sentry.io/concepts/data-management/filtering.md#ip-address) The condition matches the originating IP address of the request, with the same rules as the built-in [IP Addresses](https://docs.sentry.io/concepts/data-management/filtering.md#ip-addresses) filter. Enter a single address or a network range in CIDR notation, such as `ip_address:203.0.113.7` or `ip_address:[10.0.0.0/8,192.168.0.0/16]`. Sentry rejects a value that is not a valid address or range. Every data type carries the address, so a filter whose only conditions are IP Address conditions drops matching data of every type, whatever its data type. ### [Filter Lists from the Project Settings](https://docs.sentry.io/concepts/data-management/filtering.md#filter-lists-from-the-project-settings) The table replaces the **Custom Filters** form of the project settings. The lists of that form appear as the rows **Releases**, **Error Messages**, **Log Messages**, and **Metric Names**. A row keeps the statistics of its list. The [project details API](https://docs.sentry.io/api/projects/update-a-project.md) still reads and writes the lists as the `filters:releases`, `filters:error_messages`, `filters:log_messages`, and `filters:trace_metric_names` options, and the row shows every change. Such a row keeps its data type and its single property. You edit its patterns one per line, as the form did. You can rename the row and switch it off. Deleting the row empties the list. In the API, the row has `legacyFilter` set. Unlike the Error Message property, the **Error Messages** list matches the combined `{exception.type}: {exception.value}` description of an error. A pattern such as `TypeError: *` only works in this list. ### [Filter Names](https://docs.sentry.io/concepts/data-management/filtering.md#filter-names) If AI features are enabled for your organization, Sentry suggests a name from the conditions when you leave the name empty. You can replace the suggestion with your own name. ### [Filter Statistics](https://docs.sentry.io/concepts/data-management/filtering.md#filter-statistics) The **Trend** and **Filtered** columns of the table show how much data each filter dropped in the last 30 days, split by data category. The [Stats](https://docs.sentry.io/product/stats.md) page counts this data as filtered. ### [Custom Filter API](https://docs.sentry.io/concepts/data-management/filtering.md#custom-filter-api) You can also manage custom filters with the API. See the [custom inbound filter endpoints](https://docs.sentry.io/api/projects/list-a-projects-custom-inbound-filters.md) in the API reference. These endpoints are experimental and may change. The built-in filters on this page use the separate [data filters](https://docs.sentry.io/api/projects/list-a-projects-data-filters.md) endpoints. A filter in the API uses the keys of the [conditions](https://docs.sentry.io/concepts/data-management/filtering.md#conditions) and [operators](https://docs.sentry.io/concepts/data-management/filtering.md#operators) tables. For example, this body creates a filter that drops `TypeError` events that mention "undefined" from releases before 2.0.0: ```json { "name": "Drop TypeErrors from the 1.x releases", "dataType": "error", "conditions": [ { "type": "error_type", "operator": "equals", "value": ["TypeError"] }, { "type": "error_message", "operator": "contains", "value": ["undefined"] }, { "type": "release", "operator": "lt", "value": ["2.0.0"] } ] } ``` ## [Legacy Custom Filters](https://docs.sentry.io/concepts/data-management/filtering.md#legacy-custom-filters) This feature is available only if your organization is on [a Trial, Business, or Enterprise plan](https://sentry.io/pricing/). Projects not in the Early Adopter program filter error messages, releases, log messages, and application metrics with the **Custom Filters** form in [**Project Settings > Inbound Filters**](https://sentry.io/orgredirect/organizations/:orgslug/settings/projects/:projectId/filters/data-filters/). Each list holds glob patterns, one per line. For projects in the Early Adopter program, these lists appear as rows of the [custom filters](https://docs.sentry.io/concepts/data-management/filtering.md#filter-lists-from-the-project-settings) table. Inbound data filters are not case-sensitive. ### [Error Message](https://docs.sentry.io/concepts/data-management/filtering.md#error-message-1) 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. ##### Note Matching on the deobfuscated `{exception.type}` is not supported for [ProGuard](https://docs.sentry.io/platform-redirect.md?next=%2Fenhance-errors%2Fproguard%2F) events, because deobfuscation of class names happens after ingestion. ### [Releases](https://docs.sentry.io/concepts/data-management/filtering.md#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. ### [Log Message](https://docs.sentry.io/concepts/data-management/filtering.md#log-message-1) To use inbound data filters for log messages, keep the following in mind: * You can provide multiple patterns, one per line. The filter applies if any of the patterns match. * On logs, the filter matches the log message in the format. We do not recommend matching the full log message, and suggest you match with wildcards. For example, to match any "Connection timeout asbq33q", use the filter `*Connection timeout*`. The wildcard matcher can be used at the beginning or end of the string. ### [Application Metrics](https://docs.sentry.io/concepts/data-management/filtering.md#application-metrics) To use inbound data filters for application metrics, keep the following in mind: * You can provide multiple patterns, one per line. The filter applies if any of the patterns match. * The filter matches on the metric name. For example, to filter all metrics under the `my_metric` namespace, use `my_metric.*`. ### [Glob Matching](https://docs.sentry.io/concepts/data-management/filtering.md#glob-matching) The error messages, log messages, application metrics, 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: ```bash touch 1.2.3 touch 1.2.4 echo 1.2.* echo 1.2.[!3] ``` ## [Troubleshooting](https://docs.sentry.io/concepts/data-management/filtering.md#troubleshooting) ### [Error Message Filters Do Not Match Deobfuscated Exception Types](https://docs.sentry.io/concepts/data-management/filtering.md#error-message-filters-do-not-match-deobfuscated-exception-types) Inbound filters run immediately after Sentry receives an event. They do not wait for later processing such as symbolication, deobfuscation, or ProGuard mapping. For error events, the Error Type and Error Message properties check the exception type and value of the ingested event, and the Error Messages list checks `{exception.type}: {exception.value}` of the ingested event. The filter form warns you about this when the platform of the project usually ships obfuscated code. If an error message filter does not filter an event, compare the filter against the event as Sentry received it, not only the issue title shown after processing. To find the original exception type, open the event JSON by clicking **View JSON** in the event header, then check `exception.values.raw_type`. For example, a filter such as `MyExceptionType: *` only matches events whose incoming exception type is `MyExceptionType`. If the app sent an obfuscated exception type, such as `x`, and Sentry later deobfuscated it to `MyExceptionType`, the event JSON may show `raw_type: "x"` while the issue title shows `MyExceptionType`. In that case, filter on the incoming exception type or configure your obfuscator to keep that exception type unchanged.