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

# Filtering | Sentry for Sidekiq

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/ruby/guides/sidekiq/configuration/filtering.md#filtering-error-events)

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

### [Using `before_send`](https://docs.sentry.io/platforms/ruby/guides/sidekiq/configuration/filtering.md#using-before-send)

All Sentry SDKs support the `before_send` 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. `before_send` receives the event object as a parameter, which you can use to either modify the event’s data or drop it completely by returning `nil`, based on custom logic and the data available on the event.

```ruby
Sentry.init do |config|
  # ...
  config.before_send = lambda do |event, hint|
    # skip ZeroDivisionError exceptions
    # note: hint[:exception] would be a String if you use async callback
    if hint[:exception].is_a?(ZeroDivisionError)
      nil
    else
      event
    end
  end
end
```

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/ruby/guides/sidekiq/configuration/filtering.md#event-hints)

The `before_send` 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:

```ruby
Sentry.init do |config|
  # ...
  config.before_send = lambda do |event, hint|
    if hint[:exception].is_a?(ActiveRecord::ConnectionNotEstablished)
      event.fingerprint = ["database-unavailable"]
    end

    event
  end
end
```

For information about which hints are available see [hints in Ruby](https://docs.sentry.io/platforms/ruby/guides/sidekiq/configuration/filtering.md#using-hints).

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 (`before_send`, `before_breadcrumb` and event processors).

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

Hints are available in two places:

1. `before_send` / `before_breadcrumb`
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.

```ruby
Sentry.init do |config|
  # ...
  config.before_send = lambda do |event, hint|
    if hint[:exception].is_a?(ActiveRecord::ConnectionNotEstablished)
      event.fingerprint = ["database-unavailable"]
    end

    event
  end
end
```

#### [Hints for Events](https://docs.sentry.io/platforms/ruby/guides/sidekiq/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/ruby/guides/sidekiq/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.

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

To prevent certain transactions from being reported to Sentry, use the `traces_sampler` or `before_send_transaction` configuration option, which allows you to provide a function to evaluate the current transaction and drop it if it's not one you want.

### [Using `traces_sampler`](https://docs.sentry.io/platforms/ruby/guides/sidekiq/configuration/filtering.md#using-traces-sampler)

**Note:** The `traces_sampler` and `traces_sample_rate` config options are mutually exclusive. If you define a `traces_sampler` 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.

In its simplest form, used just for filtering the transaction, it looks like this:

```ruby
Sentry.init do |config|
  #...
  config.traces_sampler = lambda do |sampling_context|
    # transaction_context is the transaction object in hash form
    # keep in mind that sampling happens right after the transaction is initialized
    # for example, at the beginning of the request
    transaction_context = sampling_context[:transaction_context]

    # transaction_context helps you sample transactions with more sophistication
    # for example, you can provide different sample rates based on the operation or name
    op = transaction_context[:op]
    transaction_name = transaction_context[:name]

    case op
    when /http/
      case transaction_name
      when /health_check/
        0.0 # ignore health_check requests
      else
        0.1
      end
    else
      0.0 # ignore all other transactions
    end
  end
end
```

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 `traces_sampler` 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/ruby/guides/sidekiq/configuration/sampling.md#inheritance) to learn more.

Learn more about [configuring the sample rate](https://docs.sentry.io/platforms/ruby/guides/sidekiq/configuration/sampling.md).

### [Using `before_send_transaction`](https://docs.sentry.io/platforms/ruby/guides/sidekiq/configuration/filtering.md#using-before-send-transaction)

```ruby
Sentry.init do |config|
  # ...
  config.before_send_transaction = lambda do |event, _hint|
    # skip unimportant transactions
    if event.transaction == "/unimportant/healthcheck/route"
      # don't send the event to Sentry
      nil
    else
      # filter out SQL queries from spans with sensitive data
      event.spans.each do |span|
        span[:description] = '<FILTERED>' if span[:op].start_with?('db')
      end

      event
    end
  end
end
```