How to Control Sentry Error Counts and Protect Your Quota

In this article, I will explain how to stop specific errors from being sent in large quantities in Sentry and how to prevent such situations from occurring.

Introduction

Sentry is a SaaS that catches and sends errors occurring in your product, accumulating information such as occurrence locations and stack traces. While it is a very convenient tool, there is a limit (quota) on the number of errors that can be sent for each plan. Large volumes of errors can be sent unknowingly, potentially exhausting the quota.

Once you exhaust the quota, after a certain grace period, all errors will be ruthlessly discarded until the next billing cycle. By that time, we have often become so dependent on Sentry that not being able to detect errors is too terrifying, leading to a situation where we are forced to pay for additional capacity.

Target Audience

• Those who want to know the conditions under which quotas are consumed by errors
• Those who are currently in a critical situation with a large number of errors being sent
• Those who want to prevent quota consumption in advance

Conditions for Quota Consumption

First, let's check the conditions under which the quota is consumed.

This is explained on the "Quota Management" page of the official documentation.

https://docs.sentry.io/product/accounts/quotas/#what-counts-toward-my-quota-table-view

At the time of writing, it is described as follows:

Cases where consumed

First, the main cases where the quota is consumed are as follows:

A common misunderstanding is that even if an error is "Ignored," the quota is still consumed.

• When the same error occurs again after Resolving the error
• When the same error occurs again after Ignoring the error

Cases where not consumed

Next, the main cases where the quota is not consumed are as follows:

You will see that quota consumption can be suppressed in surprisingly many ways.

• When the same error occurs again after selecting "Delete and discard future events"
• When excluded by Inbound Filters
• When excluded by Spike Protection
• When excluded by SDK-side filters or settings
• When excluded by Rate Limits

How to Urgently Stop Specific Errors from Consuming Quota

First, I will explain how to handle situations where a specific error is consuming the quota and you want to stop it urgently.

Operations in Issues

If a single specific issue is consuming the quota, you can manage it from the corresponding issue page.

Delete and discard

You must be on a Business plan or higher to use this feature^[1].

When a single specific issue consumes the quota, it's common for it to be "Ignored," but that only stops the notifications while the quota continues to be consumed.

Select "Delete and discard future events" instead of "Ignore." After that, if the same issue occurs, it will be automatically discarded without consuming the quota. Another key feature is that it doesn't require high-level permissions for the operating user. If you are on a Business plan or higher, this should cover most cases.

On the other hand, since this feature is unavailable in lower plans, you will need to filter it via the SDK. This will be discussed later.

You can select it by clicking the "..." button

Operations in Inbound Filters

If you want to customize filtering instead of targeting a single specific issue, set up Inbound Filters.

You can configure this from "Project Settings" → "PROCESSING" → "Inbound Filters."

https://docs.sentry.io/product/data-management-settings/filtering/

Filter errors with glob patterns

You must be on a Business plan or higher to use this feature.

If error messages are not identical and result in separate issues, a new issue will still be created even if you use "Delete and discard." If only some parts of the string differ, you can filter specific errors by setting a glob pattern in "Error Message."

Since this feature is also unavailable in lower plans, you will need to filter it via the SDK. This will be discussed later.

Filter error messages using glob patterns

Filter errors from specific release versions

This feature requires a Business plan or higher.

Alternatively, by setting a specific version in Releases, you can filter errors from that version.

Filter release versions using glob patterns

Filter errors from specific users

If a specific user is sending a large number of errors using Internet Explorer or repeating retries, you can address this by filtering the browser or that user's IP address.

There is an item called "Filter out known errors from legacy browsers" in Inbound Filters.

With this setting, you can filter errors from old browsers like Internet Explorer.

Filter legacy browsers

On the other hand, you can filter errors from specific IP addresses using the "IP Addresses" item.

Filter IP addresses

How to Prevent Quota Consumption in Advance

Next, I will explain how to prevent such situations from occurring in the first place.

Spike Protection

Spike Protection is a feature that ignores errors when a large volume of errors occurs within a certain period.

It is enabled by default, but if it is disabled, you should enable it.

You can configure it from "Organization Settings" → "Spike Protection."

The algorithm is described in the documentation. Since the activation criteria are relatively loose, it is best to consider it as a last line of defense.

https://docs.sentry.io/product/accounts/quotas/spike-protection/

SDK Configuration

You can suppress error transmission by changing the SDK configuration.

Here are some settings that are relatively easy to configure.

https://docs.sentry.io/platforms/javascript/configuration/options/

(Since these are based on the JavaScript SDK, they may not be available for other technical stacks.)

sampleRate

By setting sampleRate, you can control the percentage of errors that are sent. For example, if you set it to 0.1, only 10% of errors will be sent.

However, since the selection of errors to send is random, there is a risk of missing infrequent errors or taking longer to detect them.

ignoreErrors

By setting ignoreErrors, you can ignore specific errors by specifying their messages with regular expressions.

While filtering with Inbound Filters is only available on Business plans or higher, this can be used on lower-tier plans as well.

denyUrls / allowUrls

By setting denyUrls / allowUrls, you can ignore errors from third-party libraries.

A common scenario is when a tracking tool you've embedded fails, causing errors to be sent from all users (this happened with Lucky Orange in the past...). You can reduce this risk by using allowUrls to filter out errors from sources other than your own product in advance.

Spend Allocation

You must be on a Business plan or higher to use this feature.

Spend Allocation allows you to set error quotas for each project. This ensures that even if errors increase drastically, the impact is confined within that project.

You can configure this from "Settings" → "Spend Allocation."

https://docs.sentry.io/product/accounts/quotas/spend-allocation/

Rate Limits

You must be on a Business plan or higher to use this feature.

Rate Limits allow you to specify the maximum number of errors accepted within a certain period for each project. This enables you to limit the number of accepted errors even during a sudden surge.

You can configure this from "Project Settings" → "Client Keys (DSN)."

https://docs.sentry.io/product/accounts/quotas/manage-event-stream-guide/#6-rate-limiting

Summary

I have introduced how quota consumption works in Sentry, along with measures and preventive steps to reduce it.

If you are on a Business plan or higher, I recommend using Spend Allocation and Rate Limits for prevention, while leveraging "Delete and discard" for issue exclusion and Inbound Filters.

For lower-tier plans, it is recommended to perform prevention and filtering by changing the SDK settings.

脚注

1. As an aside, I'm impressed by the clever design—in a good way—where lower-tier plans tend to accumulate more errors due to limited features. If you want to upgrade to a Business plan but can't secure the budget, consider highlighting the benefit of reducing additional billing by cutting down the number of errors.