Quota Management

Events and quotas are interconnected in Sentry. At the most basic, when you subscribe to Sentry, you pay for the number of events - errors, attachments, and transactions - to be tracked. Each of these type of events has a quota. When Sentry accepts an event, it counts toward your quota for that type of event.

Sentry’s flexibility means you can exercise fine-grained control over which events count toward your quota.

Key Terms

Let’s clarify a few terms to start:

  • Event - An event is one instance of you sending data to Sentry. Generally, this data is an error or a transaction.
  • Issue - An issue is a grouping of similar error events. Every error event has a set of characteristics called its fingerprint, which is what Sentry uses for grouping. For example, Sentry groups events together when they are triggered by the same part of your code. Learn more in our full Issue Grouping documentation.
  • Attachment - Attachments are files uploaded in the same request, such as log files. Unless the option to store crash reports is enabled, Sentry will use these files only to create an event, and then drop them.
  • Transaction - A transaction represents a single instance of a service being called to support an operation you want to measure or track, like a page load. Transaction events are grouped by the transaction name.
  • Quota - Your quota is the monthly number of events — errors, attachments, and transactions — that you pay Sentry to track.

What Counts Toward My Quota, an Overview

Sentry completes a thorough evaluation of each event to determine if it counts toward your quota, as outlined in this overview. Detailed documentation for each evaluation is linked throughout. Before completing any of these evaluations, Sentry confirms that each event includes a valid DSN and project as well as whether the event can be parsed. In addition, for error events, Sentry validates that the event contains valid fingerprint information. If any of these items are missing or incorrect, the event is rejected.

  1. SDK configuration

    The SDK configuration either allows the event or filters the event out. Learn more in errors and transactions quota management docs or in the filtering docs for your specific SDK.

  2. SDK sample rate

    If a sample rate is defined for the SDK, the SDK evaluates whether this event should be sent as a representative fraction of events. Setting a sample rate is documented for each SDK. The SDK sample rate is not dynamic; changing it requires re-deployment. In addition, setting an SDK sample rate limits visibility into the source of events. Setting a rate limit for your project may better suit your needs.

  3. Quota availability

    Events that exceed your quota are not accepted. Once your event volume is approaching or has exceeded the quota, teammates with the "owner" organization permission level will receive notification emails. Learn about adding to your quota and what happens when you exceed it in Increasing Quotas.

  4. Event repetition

    Event repetition only applies to error events, not transactions or attachments. The following rules apply for event repetition and your quota:

    • If you have chosen to "Delete & Discard" an issue, then future error events with the same fingerprint do not count toward your quota.
    • If you previously resolved an issue, a new error event counts toward your quota because it may represent a regression in your code.
    • If you have chosen to ignore alerts about error events with the same fingerprint, a new event counts toward your quota because the event is still occurring. Learn more in Inbound Filters.
  5. Spike protection

    Sentry’s spike protection prevents huge overages in error events from consuming your event capacity. Spike protection is not currently available for transactions. Learn more in Spike Protection.

In addition, depending on your project’s configuration and the plan you subscribe to, Sentry may also check:

  1. Rate limit for the project

    If the error event rate limit for a project has been exceeded, and your subscription allows, the event will not be counted. Learn more in Rate Limiting or in Error Event Limits. This does not apply to transactions or attachments.

  2. Inbound filters

    If any inbound filter is set for a type of error event, and your subscription allows, the event will not be counted. Learn more in the Inbound Filters section of our error quota management guide or in Inbound Data Filter. This does not apply to transactions or attachments.

After these checks are processed, the event counts toward your quota. It is accepted into Sentry, where it persists and is stored.

What Counts Toward my Quota, Table View

Yes, this event countsNo, this event does not count
SDK configurationNot setSet to filter this event
SDK sample rateNot setSet
QuotaNot reachedExceeded
Are future error events that repeat set to Delete & Discard?No
Is this a repeated error event for a previously resolved issue?Yes, this may be a regression in your code
Is this repeated error event set to Ignore Alert?Yes, it is still occurring
Has spike protection (errors only) been triggered?NoYes
Rate limit for error events for the projectNot set or not reachedSet and exceeded
Inbound filters (errors only)Not setSet for this error event

Increasing Quotas

Add to your quota at any time during your billing period by either upgrading to a higher plan or tier, increasing your reserved capacity, or increasing your on-demand capacity. To increase your quota, go to Settings > Subscription and click the "Manage Subscription" button to access your subscription options. When you increase your quota, the change goes into effect immediately.

If you exceed your quota threshold, the server will respond with a 429 HTTP status code, which communicates to SDKs and clients to stop sending events. This status code comes with a Retry-After header that indicates the time for which this rate limit is active. However, clients are not supposed to retry events, but instead drop events until the rate limit has expired, to prevent queue backlogs. Note, that since event ingestion and rate limiting happen asynchronously, the 429 HTTP status code is always slightly delayed.

If this is your first time exceeding quota, however, you'll be entered into a one-time grace period. Learn more about the grace period in this Help article.

On-Demand Capacity

If you need to increase your event quota temporarily, we recommend that you add or increase on-demand capacity. This is ideal for situations like rolling out a new version of your application where you anticipate more events for the month. To add on-demand capacity, you enter a monthly maximum budget on either a shared or per-category (errors, transactions, and attachments) basis. Learn more about on-demand capacity in our pricing documentation.

Reserved Capacity

If the number of events you need is steadily increasing, you may want to increase your reserved capacity. Reserved capacity is less expensive than on-demand capacity since you prepay for it. It also allows you to choose the number of events that you want to have available beforehand rather than just setting an arbitrary on-demand budget. Learn more about reserved capacity in our pricing documentation.

You shouldn't increase your reserved capacity if you think your need for more events is temporary, since reducing your reserved capacity is tied to your billing cycle.

Plan Upgrade

If you're on a Developer plan and want to increase your quota, you'll need to upgrade to a Team or Business plan. On these plans you can prepay for more event capacity and purchase on-demand capacity, as needed. Learn about Sentry's plans on our pricing page.

Decreasing Quotas

Plan downgrades and decreases in reserved capacity are processed at the end of your billing cycle, and remaining capacity cannot be refunded. For example, if you have a monthly billing cycle that starts on the 5th of the month, and you decrease your reserved capacity on June 20th, then this change will be processed on July 4th. Your billing cycle beginning on July 5th will reflect your new reserved capacity.

Changes to on-demand capacity typically go into effect immediately and are guaranteed to go into effect within 24 hours.

To decrease your quota, go to Settings > Subscription and click "Manage Subscriptions". When you reach the "Review & Confirm" step, the date that these changes go into effect will be displayed:

The Review & Confirm step of a subscription update.

Limiting Events

You can add limits for error events and attachments in sentry.io. This does not apply to transaction events.

Error Event Limits

Per-key rate limits allow you to set the maximum volume of error events a key will accept during a period of time.

For example, you may have a project in production that generates a lot of noise. A rate limit allows you to set the maximum amount of data to “500 events per minute”. Additionally, you can create a second key for the same project for your staging environment, which is unlimited, ensuring your QA process is still untouched.

To set up rate limits, navigate to [Project] > Settings > Client Keys and click "Configure"**". Select an individual key or create a new one, then you’ll be able to define a rate limit as well as view a breakdown of events received by that key. For additional information and examples, see Rate Limiting in our guide to managing your error quota.

Attachment Limits

If you have enabled the storage of crash reports, you may set limits for the maximum number of crash reports that will be stored per issue. To set up these limits, use the slider in the "Store Native Crash Reports" option in your organization's "Security & Privacy" settings.

Inbound Filters

In some cases, the data you’re receiving in Sentry is hard to filter, or you don’t have the ability to update the SDK’s configuration to apply the filters. Sentry provides several methods to filter error events server-side, which apply before checking for potential rate limits. This does not apply to transaction events or attachments.

Inbound filters include:

  • Common browser extension errors
  • Events coming from localhost
  • Known legacy browsers errors
  • Known web crawlers
  • By their error message
  • From specific release versions of your code
  • From certain IP addresses.

Explore these by navigating to [Project] > Settings > Inbound Filters. Commonly-set filters are discussed here for your quick reference. For additional information and examples, see Inbound Data Filters in our guide to managing your error quota. Commonly-set filters include:

IP Filters

If you have a rogue client, Sentry supports blocking an IP from sending data. Navigate to [Project] > Settings > Inbound Filters to add the IP addresses (or subnets) in the "IP Addresses" field.

Filter by Release

If you discover a problematic release causing excessive noise, Sentry supports ignoring all events from that release. Navigate to [Project] > Settings > Inbound Filters, then add the releases to the "Releases" field

Filter by Error Message

Sentry supports filtering out a specific or certain kind of error as well. Navigate to [Project] > Settings > Inbound Filters, then add the error message to the "Error Message" field.

To ensure you’re adding the correct message to the inbound filter setting, check the JSON for an event in the issue. The filter by error message setting matches the data found in the "title" field near the end of the file.

Filter by Issue

When you are unable to take immediate action on an issue, but it continues to occur, Sentry supports deleting and discarding that issue, which you can do from the Issue Details page. Navigate to the issue you would like to filter, click on the drop-down menu next to the bin icon, and select “Delete and discard future events”. This setting deletes most data associated with the issue and filters out new matching events before they count against your quota.

You can view and restore previously discarded issues by navigating to the "Discarded Issues" tab of [Project] > Settings > Inbound Filters.

Spike Protection

A spike is both a large and temporary increase in error event volume. Because Sentry bills based on monthly event volume, spikes can easily consume your capacity for the rest of the month. Sentry's spike protection prevents these types of overages from consuming your error event capacity by dropping error events during the spike.

Spike protection is an organization-level setting, so once it's triggered, it affects all the projects in the organization, regardless of which project triggered the spike.

Spike protection is enabled for your organization by default, and when it's enabled, Sentry continually monitors for spikes. If you want to disable it, you can do so in Settings > Subscription.

How Does Spike Protection Work?

We use your historical error event volume to implement a dynamic rate limit, and then discard error events when you hit its threshold. When spike protection is activated, we limit the number of error events accepted in any minute to:

maximum(20, 6 x average error events per minute over the last 24 hours)

This means if you experience a spike, we'll temporarily protect you, but if the increase in volume is sustained, the spike protection limit will gradually increase until Sentry accepts all events.

For example, in the last 24 hours, your organization has been receiving, on average, 10 events per minute (after any inbound filters have been applied). That means your current per-minute limit is 6 * 10 or 60 events. There have been no spikes in that time, so spike control is "inactive". Something breaks, and in the next minute, your organization sends Sentry 100 events. When we see the 61st event, three things happen:

  1. Spike protection becomes "active".

  2. If your organization has used more than 25% of your monthly quota, Sentry sends the organization owner a notification including which project the 61st event came from. This is likely, but not guaranteed to be, the project in which something broke.

  3. Events 61-100 are dropped.

When the next minute begins, we again record up to 60 events, dropping the rest until the minute is up. It continues like this for the remainder of the hour. After an hour, we re-calculate your per-minute limit, and for the next hour use that limit to decide whether events get dropped each minute. We repeat this process every hour until Sentry eventually accepts all events.

If, instead of a single big spike (or an overall, permanent, increase in traffic), you experience many small spikes, there may be many days in a row when at least a few events are dropped. In that scenario, spike protection remains active the entire time.

When Does Spike Protection Become "Inactive?"

Events will not be dropped during any minute in which you don't send more than the hourly limit that Sentry has calculated for you. After 24 hours without any dropped events, spike protection becomes "inactive" again. This means that it is no longer dropping events, but it does not mean the system has stopped paying attention. It does however mean that the next time events are dropped, with respect to alerts it will count as a "reactivation" of spike protection.

Size Limits

Sentry imposes limits on various fields within an event, as well as the size of full events and the requests they are sent in:

  • Events, attachments, and requests exceeding payload size limits are immediately dropped with a 413 Payload Too Large error. Sentry allows compressed content encoding, and applies separate limits before and after decompression.
  • Fields exceeding the individual size limits are afterwards trimmed and truncated at a best effort.

To avoid unintentional data loss, consider limiting the size of values passed into Sentry's APIs. For example, if your application attaches application state or request bodies to Sentry events, truncate them first.

The precise limits may change over time. For more information, please refer to the following resources:

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