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
- Receive more actionable and meaningful error events.
- Reserve real-time notifications for errors that actually break your code.
- 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.
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.
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.
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
denyUrlson the SDK can be used to block subdomains of the domains listed in
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:
To learn more and see code samples, check out:
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.
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
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.
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.
For more information on the fingerprint algorithm and customizing event grouping, check out our Issue Grouping docs.
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.
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.
This feature is available only on a Business plan or higher.
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.
Once you've identified a set of discarded issues, it might make sense to go back to your SDK configuration and add the related errors into your
before-send client-side filtering.
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
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.
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 DAYSgraph 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.
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.
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.
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.
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.
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
You can also download monthly reports that provide a breakdown of events by project under Settings > Subscription in the "Usage History" tab.
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
count(), as shown below:
Once the changes are applied, sort the "Results" table by the "COUNT" column to display your busiest issues: