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 BeforeSend callback method and configuring, enabling, or disabling integrations.

Using BeforeSend

All Sentry SDKs support the BeforeSend callback method. BeforeSend 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.

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

using Sentry;

// Add this to the SDK initialization callback
options.SetBeforeSend((sentryEvent, hint) =>
    if (sentryEvent.Exception != null
      && sentryEvent.Exception.Message.Contains("Noisy Exception"))
        return null; // Don't send this event to Sentry

    sentryEvent.ServerName = null; // Never send Server Name to Sentry
    return sentryEvent;

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

Filtering Transaction Events

To prevent certain transactions from being reported to Sentry, use the TracesSampler or BeforeSendTransaction 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 TracesSampler

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.

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

// Add this to the SDK initialization callback
options.TracesSampler = samplingContext =>
    if (/* make a decision based on `samplingContext` */) {
      // Drop this transaction, by setting its sample rate to 0%
      return 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;

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 to learn more.

Learn more about configuring the sample rate.

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