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.
Let’s clarify a few terms to start:
- Event - an event is one instance of you sending Sentry data. Generally, this data is an error. Every event has a set of characteristics, called its fingerprint.
- Issue - an issue is a grouping of similar events, which all share the same fingerprint. For example, Sentry groups events together when they are triggered by the same part of your code. For more information, see Grouping & Fingerprinting.
- 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 the files only to create the event, and then drop the files.
- 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.
- Quota - your quota is the monthly number of events - errors, attachments, and transactions - you pay Sentry to track.
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.
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.
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. To add to your quota or review what happens when you exceed it, see Increasing Quotas.
- If you have intervened to Delete and Discard an issue, then future events with the same fingerprint do not count toward your quota.
- If the previous event was resolved, this event counts toward your quota because it may represent a regression in your code.
- If you have intervened to ignore alerts about events with the same fingerprint, this event counts toward your quota because the event is still occurring. For more information, see Inbound Filters.
Sentry’s spike protection prevents huge overages from consuming your event capacity; spike protection is not currently available for transactions. For more information, see Spike Protection.
In addition, depending on your project’s configuration and the plan you subscribe to, Sentry may also check:
Rate limit for the project
If the error event rate limit for the project has been exceeded, and your subscription allows, the event will not be counted. For more information, see Rate Limiting in our guide to Manage Your Event Stream or Error Event Limits.
If any inbound filter is set for this type of error event, and your subscription allows, the event will not be counted. For more information, see Inbound Filters in our guide to Manage Your Event Stream or Inbound Data Filter.
After these checks are processed, the event counts toward your quota. It is accepted into Sentry, where it persists and is stored.
|Yes, this event counts||No, this event does not count|
|SDK configuration||Not set||Set to filter this event|
|SDK sample rate||Not set||Set|
|Are future error events that repeat set to Delete & Discard?||No|
|Is this repeated event resolved?||Yes, this may be a regression in your code|
|Is this repeated event set to Ignore Alert?||Yes, it is still occurring|
|Has spike protection been triggered?||No||Yes|
|Rate limit for error events for the project||Not set or not reached||Set and exceeded|
|Inbound Filters||Not set||Set for this error event|
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’ve exceeded your quota threshold, the server will respond with a 429 HTTP status code. However, if this is your first time exceeding quota, you'll be entered into a one-time grace period. Learn more about the grace period in this Help article.
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 spending cap. Learn more about on-demand capacity in our pricing documentation.
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 rather than just setting a maximum spending cap. 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.
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.
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:
We strongly recommend that you make subscription changes before the last day of your billing cycle. Depending on your time zone, in some cases, changes made on the last day of the billing cycle will not go into effect until the next billing cycle.
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] » Client Keys » 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 Manage Your Event Stream.
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 for your organization's Security and Privacy Settings.
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 data server-side, which apply before checking for potential rate limits. 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] » 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 Manage Your Event Stream. Commonly-set filters include:
If you have a rogue client, Sentry supports blocking an IP from sending data. Navigate to [Project] » Project Settings » Inbound Filters to add the IP addresses (or subnets) to Filter errors from these IP addresses.
If you discover a problematic release causing excessive noise, Sentry supports ignoring all events from that release. Navigate to [Project] » Project Settings » Inbound Filters, then add the releases to Filter errors from these releases.
Sentry supports filtering out a specific or certain kind of error as well. Navigate to [Project] » Project Settings » Inbound Filters, then add the error message to Filter errors by error message.
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 [Project] » Project Settings » Inbound Filters » Discarded Issues.
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.
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)
The 24-hour window ends at the beginning of the current hour, not at the current minute.
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:
Spike protection becomes "active".
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.
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.
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.
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 Largeerror. 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: