---
title: "Filtering"
description: "Learn more about how to configure your SDK to filter events reported to Sentry."
url: https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering/
---

# Filtering | Sentry for Spring Boot

When you add Sentry to your app, you get a lot of valuable information about errors and performance. And lots of information is good -- as long as it's the right information, at a reasonable volume.

The Sentry SDKs have several configuration options to help you filter out events.

We also offer [Inbound Filters](https://docs.sentry.io/concepts/data-management/filtering.md) to filter events in sentry.io. We recommend filtering at the client level though, because it removes the overhead of sending events you don't actually want. Learn more about the [fields available in an event](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/).

## [Filtering Error Events](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#filtering-error-events)

Configure your SDK to filter error events by using the `ignoredErrors` option or the `beforeSend` callback method and configuring, enabling, or disabling integrations.

### [Using `ignoredErrors`](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#using-ignored-errors)

You can use the `ignoredErrors` option to filter out errors that match a certain pattern. This option receives a list of strings and regular expressions to match against the error message. When using strings, full matches will be filtered out.

```properties
ignored-errors=Some error,Another .*
```

### [Using `beforeSend`](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#using-before-send)

All Sentry SDKs support the `beforeSend` callback method. Because it's called immediately before the event is sent to the server, this is your last chance to decide not to send data or to edit it. `beforeSend` receives the event object as a parameter, which you can use to either modify the event’s data or drop it completely by returning `null`, based on custom logic and the data available on the event.

`beforeSend` callback can be registered by creating a Spring bean implementing the `BeforeSendCallback`.

```java
import io.sentry.SentryEvent;
import io.sentry.SentryOptions;
import io.sentry.Hint
import org.springframework.stereotype.Component;

@Component
public class CustomBeforeSendCallback implements SentryOptions.BeforeSendCallback {
  @Override
  public SentryEvent execute(SentryEvent event, Hint hint) {
    // Example: Never send server name in events
    event.setServerName(null);
    return event;
  }
}
```

Note also that breadcrumbs can be filtered, as discussed in [our Breadcrumbs documentation](https://docs.sentry.io/product/error-monitoring/breadcrumbs.md).

#### [Event Hints](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#event-hints)

The `beforeSend` callback is passed both the `event` and a second argument, `hint`, that holds one or more hints.

Typically, a `hint` holds the original exception so that additional data can be extracted or grouping is affected. In this example, the fingerprint is forced to a common value if an exception of a certain type has been caught:

A `BiFunction<SentryEvent, Hint, SentryEvent>` can be used to mutate, discard (return null), or return a completely new event.

```java
import io.sentry.SentryEvent;
import io.sentry.SentryOptions;
import io.sentry.Hint
import org.springframework.stereotype.Component;

@Component
public class CustomBeforeSendCallback implements SentryOptions.BeforeSendCallback {
  @Override
  public SentryEvent execute(SentryEvent event, Hint hint) {
    if (hint.get("my-hint-key") != null) {
      return null;
    } else {
      return event;
    }
  }
}
```

When the SDK creates an event or breadcrumb for transmission, that transmission is typically created from some sort of source object. For instance, an error event is typically created from a log record or exception instance. For better customization, the SDK sends these objects to certain callbacks (`beforeSend`, `beforeBreadcrumb` and event processors).

### [Using Hints](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#using-hints)

Hints are available in two places:

1. `beforeSend` / `beforeBreadcrumb`
2. `eventProcessors`

Event and breadcrumb `hints` are objects containing various information used to put together an event or a breadcrumb. Typically `hints` hold the original exception so that additional data can be extracted or grouping can be affected.

For events, hints contain properties such as `event_id`, `originalException`, `syntheticException` (used internally to generate cleaner stack trace), and any other arbitrary `data` that you attach.

For breadcrumbs, the use of `hints` depends on the type of breadcrumb.

```java
import io.sentry.SentryEvent;
import io.sentry.SentryOptions;
import io.sentry.Hint
import org.springframework.stereotype.Component;

@Component
public class CustomBeforeSendCallback implements SentryOptions.BeforeSendCallback {
  @Override
  public SentryEvent execute(SentryEvent event, Hint hint) {
    if (event.getThrowable() instanceof SQLException) {
      event.setFingerprints(Arrays.asList("database-connection-error"));
    }
    return event;
  }
}
```

#### [Hints for Events](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#hints-for-events)

`originalException`

The original exception that caused the Sentry SDK to create the event. This is useful for changing how the Sentry SDK groups events or to extract additional information.

`syntheticException`

When a string or a non-error object is raised, Sentry creates a synthetic exception so you can get a basic stack trace. This exception is stored here for further data extraction.

#### [Hints for Breadcrumbs](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#hints-for-breadcrumbs)

`event`

For breadcrumbs created from browser events, the Sentry SDK often supplies the event to the breadcrumb as a hint. This can be used to extract data from the target DOM element into a breadcrumb, for example.

`level` / `input`

For breadcrumbs created from console log interceptions. This holds the original console log level and the original input data to the log function.

`response` / `input`

For breadcrumbs created from HTTP requests. This holds the response object (from the fetch API) and the input parameters to the fetch function.

`request` / `response` / `event`

For breadcrumbs created from HTTP requests. This holds the request and response object (from the node HTTP API) as well as the node event (`response` or `error`).

`xhr`

For breadcrumbs created from HTTP requests made using the legacy `XMLHttpRequest` API. This holds the original `xhr` object.

### [Decluttering Sentry](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#decluttering-sentry)

When used together with one of the logging framework integrations, the Java SDK captures all error logs as events. If you see a particular kind of error very often that has a `logger` tag, you can ignore that particular logger entirely. For more information see our [Logback](https://docs.sentry.io/platforms/java/guides/logback.md) or [Log4j 2](https://docs.sentry.io/platforms/java/guides/log4j2.md) integration.

## [Filtering Transaction Events](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#filtering-transaction-events)

To prevent certain transactions from being reported to Sentry, use the `ignoredTransactions` option, the `tracesSampler` option, or the `beforeSendTransaction` callback.

### [Using `ignoredTransactions`](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#using-ignored-transactions)

You can use the `ignoredTransactions` option to filter out transactions that match a certain pattern. This option receives a list of strings and regular expressions to match against the transaction name. When using strings, full matches will be filtered out.

```properties
ignored-transactions=GET /api/person,POST .*
```

### [Using `tracesSampler`](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#using-traces-sampler)

**Note:** The `tracesSampler` and `tracesSampleRate` config options are mutually exclusive. If you define a `tracesSampler` to filter out certain transactions, you must also handle the case of non-filtered transactions by returning the rate at which you'd like them sampled.

You can use the `tracesSampler` option to customize the traces sampling behavior. In its simplest form, used just for filtering the transaction, it looks like this:

```java
import io.sentry.SamplingContext;
import io.sentry.SentryOptions.TracesSamplerCallback;
import org.springframework.stereotype.Component;

@Component
class CustomTracesSamplerCallback implements TracesSamplerCallback {
  @Override
  public Double sample(SamplingContext context) {
    // If this is the continuation of a trace, just use that decision (rate controlled by the caller).
    Boolean parentSampled = context.getTransactionContext().getParentSampled();
    if (parentSampled != null) {
      return parentSampled ? 1.0 : 0.0;
    }
    CustomSamplingContext ctx = context.getCustomSamplingContext();
    if (ctx != null) {
      if (/* make a decision based on `samplingContext` */) {
        // Drop this transaction, by setting its sample rate to 0%
        return 0.0;
      } else if (/* ... */) {
        // Override sample rate for other cases (replaces `options.TracesSampleRate`)
        return 0.1;
      }
      // Can return `null` to fallback to the rate configured by `options.tracesSampleRate`
      return null;
    } else {
      return null;
    }
  }
}
```

It also allows you to sample different transactions at different rates.

If the transaction currently being processed has a parent transaction (from an upstream service calling this service), the parent (upstream) sampling decision will always be included in the sampling context data, so that your `tracesSampler` can choose whether and when to inherit that decision. In most cases, inheritance is the right choice, to avoid breaking distributed traces. A broken trace will not include all your services. See [Inheriting the parent sampling decision](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/sampling.md#inheritance) to learn more.

Learn more about [configuring the sample rate](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/sampling.md).

### [Using `beforeSendTransaction`](https://docs.sentry.io/platforms/java/guides/spring-boot/configuration/filtering.md#using-before-send-transaction)

The `beforeSendTransaction` allows you to provide a function to evaluate the current transaction and drop it if it's not one you want to capture.

`beforeSendTransaction` callback can be registered by creating a Spring bean implementing the `BeforeSendTransactionCallback`.

```java
import io.sentry.SentryTransaction;
import io.sentry.SentryOptions;
import io.sentry.Hint
import org.springframework.stereotype.Component;

@Component
public class CustomBeforeSendTransactionCallback implements SentryOptions.BeforeSendTransactionCallback {
  @Override
  public SentryTransaction execute(SentryTransaction transaction, Hint hint) {
    // Modify or drop the transaction here:
    if ("/unimportant/route".equals(transaction.getTransaction())) {
      // Don't send the transaction to Sentry
      return null;
    } else {
      return transaction;
    }
  }
}
```