Manage Your Error Quota

Sending all your application errors to Sentry ensures you'll be notified in real-time when errors occur in your code. However, with a basic setup, you may consume your error

too rapidly and trigger more notifications than you can use. Sentry provides tools to control the type and amount of errors that are monitored. These tools allow you to:

1. Receive more actionable and meaningful error events.
2. Reserve real-time notifications for errors that actually break your code.
3. Manage your error
   quotaThe monthly number of events that you pay Sentry to track.
   .

Applying the proper filters, SDK configuration, and rate limits is an iterative and on-going process, but these tips will show you how to get the most out of your error events.

1. SDK Filtering: beforeSend

All Sentry SDKs support the beforeSend callback method. Once implemented, the method is invoked when the SDK captures an event, right before sending it to your Sentry account. 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 your custom logic and the data available on the event, like tags, environment, release version, error attributes, and so on. Learn more in Filtering Events.

2. SDK Configuration

The Sentry SDKs have several configuration options that can be used to filter unwanted errors from leaving your application's runtime. A lot of these options are platform-specific, so make sure you look for yours in our docs under Platforms and Configuration. Following are some examples.

JavaScript

The JavaScript SDK includes multiple integrations: functional plugins that you can configure, enable, or disable. Learn more in JavaScript SDK Integrations. Several integrations allow you to configure the types of events you want Sentry to monitor:

InboundFilters

The integration is enabled by default and adds the following configuration options to the SDK:

• allowUrls: Domains that might raise acceptable exceptions represented in a regex pattern format.
• denyUrls: A list of strings or regex patterns which match error URLs that should be blocked from sending events. Configuring both allowUrls and denyUrls on the SDK can be used to block subdomains of the domains listed in allowUrls.
• ignoreErrors: Instruct the SDK to never send an error to Sentry if it matches any of the listed error messages or regular expressions. The SDK will try to match against the message or, if there is no message, a string containing the exception type and value formatted like so: ExceptionType: value.

To learn more and see code samples, check out:

• Filtering
• Enriching Events: Add Context

GlobalHandlers

The integration attaches global handlers to capture uncaught exceptions (onerror) and unhandled rejections (onunhandledrejection). Both handlers are enabled by default, but can be disabled through configuration. Learn more in GlobalHandlers Integration.

Check out additional configuration options with the tryCatch and ReportingObserver integrations.

Other SDKs

Java - Sentry's Java SDK provides integrations with common Java logging libraries. The configuration allows you to set a logging threshold determining the minimum level to capture a log message as breadcrumb. It also provides a setting to configure the minimum log level to capture an event.

PHP - The error_types configuration option allows you to set the error types you want Sentry to monitor. Learn more in PHP Basic Options.

Ruby - The excluded_exceptions configuration option allows you to set the exception types you wish to suppress. Learn more in the Ruby configuration docs

3. Inbound Data Filters

While SDK configuration requires changes to your source code and depends on your next deployment, server-side filters can be easily configured per project in the "Data Filters" section of [Project] > Settings > Inbound Filters. Learn more in Inbound Filters.

Once applied, you can track the filtered events (numbers and cause) using the graph provided at the top of the "Inbound Filters" page.

4. Event Grouping

Proper event grouping is essential to maintaining a meaningful set of issues and reducing redundant notifications. Sentry groups similar error events into unique issues based on their fingerprint. An event's fingerprint relies firstly on its stack trace.

With JavaScript errors, minified source code might result in a nondeterministic stack trace that could negatively affect associated event grouping. To improve grouping, make sure Sentry has access to your source maps and minified artifacts. Learn more in Source Maps.

For more information on the fingerprint algorithm and customizing event grouping, check out our Issue Grouping docs.

5. Resolve or Delete Issues

Now that your error events have been fine-tuned to reflect real problems in your code, it's an excellent practice to react to errors as they happen. If an issue reflects a real problem in your code, resolve it; otherwise, delete and discard it.

Resolve

You've been alerted on a new error in your code? Go to the Issue Details page to get all the data you need to know about the error. If it's a real issue in your code, assign a team member to resolve it. Don't forget to let Sentry know once it's resolved. Learn more about workflows for handling issues in Issue States and Triage.

Delete & Discard

If there is an irrelevant, reoccurring issue that you are unable or unwilling to resolve, you can delete and discard it from the Issue Details page by clicking "Delete and discard future events". This will remove the issue and event data from Sentry and filter out future matching events.

You can find a list of these issues in the "Discarded Issues" tab in [Project] > Settings > Inbound Filters. From here, you can un-discarded any of these issues to receive future events.

6. Rate Limiting

Rate limiting allows you to limit the amount of events Sentry accepts per project for a defined time span. While this is quite useful for managing your monthly event

, keep in mind that once a defined threshold is crossed, subsequent events will be dropped. Therefore, you shouldn't constantly be hitting your rate limit; rather, it should act as a ceiling intended to protect you from unexpected spikes.

In [Project] > Settings > Client Keys (DSN), click "Configure", and you can create multiple DSN keys per project and assign different (or no) rate limits to each key. This will allow you to dynamically allocate keys (with varying thresholds) depending on release, environment, and so on.

Setting Useful Rate Limits

A good way to set a project rate limit is by figuring out the expected event volume based on your average traffic. Let's look at an example:

• Open the project DSN key configuration under [Project] > Settings > Client Keys (DSN) by clicking "Configure".
• In the KEY USAGE IN THE LAST 30 DAYS graph and look for the highest point, or the maximum daily rate. In this example, the maximum daily rate in the last month is less than 326K.
• Based on that, we can define a ceiling daily maximum value of approximantely 330K, which is around 13,750 events an hour, or about 230 events a minute.
• You can set a daily, hourly, or minute-based rate limit. We'd recommend using a minute-based rate to avoid situations where a random event spike might exhaust your daily or hourly
  quotaThe monthly number of events that you pay Sentry to track.
  and leave you blind for a long period.

You should periodically go back and check the graph to see the number of events dropped due to rate limiting and, if needed, revisit your settings.

7. Spike Protection

Sentry also applies a dynamic rate limit to your account designed to protect you from short-term spikes. However, we still recommend applying all of the previously mentioned methods.

Managing a Spike

You might receive an email notifying you that spike protection was triggered and applied to your account.

Many times, an unexpected spike is caused by a new error (or errors) introduced into your code with a new release version. We understand that errors can come in spikes and service interruptions can be challenging, so we include a one-time grace period for all paid accounts.

If an account depletes its event capacity and has never previously triggered a grace period, we continue to accept events for the next three days at a maximum rate of 10,000 events per hour. If you choose not to increase your capacity, Sentry will stop accepting events for the remainder of the current billing month. However, if you increase your capacity, events accepted during the grace period will be counted as consumed capacity.

Once you've used your grace period, we recommend setting up an on-demand budget to ensure you have time to adjust your capacity in the event of a future spike in errors.

Also, consider doing the following:

• Set better rate limits on the DSN keys for the projects related to the spike.
• If it's a specific release version that has caused the spike, add the version identifier to the project's inbound filters to avoid accepting events from that release.

To review the error events dropped because of spike protection, go to Settings > Subscription for your Sentry org and scroll to the "Error Usage" section of the page.

Learn more about how spike protection works.

8. Event Usage Stats

Once you've completed the steps above, you can look at your events in aggregate in the "Usage Stats" tab of Stats. This information will help you answer some key questions like:

• What's the breakdowndown of my incoming events?
• Which projects are consuming my
  quotaThe monthly number of events that you pay Sentry to track.
  ?
• Which issues are consuming my
  quotaThe monthly number of events that you pay Sentry to track.
  ?

The answers to these questions can help you figure out where you need to do further fine-tuning of your filters, limits, or SDK configuration.

How can I see a breakdown of incoming events?

The Usage Stats tab displays details about the total number of events Sentry has received across your entire organization for up to 90 days. The page breaks down the events (by project) into three categories:

• Accepted: Events processed and displayed in the issues or transactions views in sentry.io.
• Dropped: Events that were discarded due to a limit being hit.
• Filtered: Events that were blocked based on your inbound filter rules.

You can also download monthly reports with a similar breakdown of all your previous billing periods under Settings > Subscription in the "Usage History" tab.

What are my busiest projects?

The "Project" table in the "Usage Stats" tab of Stats breaks down your events by project, so you can see which ones are consuming your

.Clicking on the settings icon next to a project name in the table will open the project's settings page where you can manage its inbound filters and rate limits

You can also download monthly reports that provide a breakdown of events by project under Settings > Subscription in the "Usage History" tab.

Which issues are consuming my quota?

The Sentry workflow starts with a real-time alert notifying you about an error in your code. If you want to take a more proactive approach to resolving your busiest issues, you can set up a query in Discover. When you're building the query, search for event.type:error and then set the columns issue, title, project, and count(), as shown below:

Once the changes are applied, sort the "Results" table by the "COUNT" column to display your busiest issues: