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 to filter events in 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.

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

All Sentry SDKs support the before_send callback method. before_send is called immediately before the event is sent to the server, so it’s the final place where you can edit its data. It receives the event object as a parameter, so you can use that to modify the event’s data or drop it completely (by returning null) based on custom logic and the data available on the event.

# sentry.ex
defmodule MyApp.Sentry do
  def before_send(%{user: user} = event) do
    # Don't send user's email address
    user = Map.delete(user, :email)
    %{event | user: user}

  def before_send(event) do

# config.exs
config :sentry,
  before_send_event: {MyApp.Sentry, :before_send},
  # ...

Note also that breadcrumbs can be filtered, as discussed in our Breadcrumbs documentation.

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 is implementation dependent. For XHR requests, the hint contains the xhr object itself; for user interactions the hint contains the DOM element and event name and so forth.

Hints for Events

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.

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

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

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

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").