Manage Your Span Units Quota
Learn how to use the tools Sentry provides to control your span unit quota.
In most cases, sending all span events to Sentry could generate more data than you'd find useful and might use up your span units too quickly. Sentry provides tools to control the type and amount of spans that are monitored. This allows you to have tracing data that's actionable and meaningful.
Applying the proper SDK configuration is an iterative and on-going process, but these tips will show you how to best use Sentry's tools to get the most out of your span units. These tips are ordered from easiest or least time-consuming to most challenging or potentially time-consuming. The first two options are things you can do in sentry.io, whereas the remaining ones are things you'll do in the SDK.
Note
The "Usage Stats" tab is only visible if you're on a Team, Business, or Enterprise plan.
You can look at your events in aggregate in the "Usage Stats" tab of Stats. This information will help you answer key questions about the breakdown of your incoming events or which projects are consuming your quota. The answers to these questions can help you figure out where you need to do further fine-tuning of your SDK filters and configuration.
This page is accessible to all members of your organization, so Owners in your Sentry org can share this page with the developers directly responsible for a given project. Also, you can come back to this page to check if the changes you've made are having the desired effect.
The Usage Stats tab displays details about the total amount of data Sentry has received across your entire organization for up to 90 days. The page breaks down the events (by project) into three categories: accepted, dropped, or filtered. Only accepted events affect your quota:
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 quota. Clicking on the settings icon next to a project name in the table will open the project's settings, where you can manage its inbound filters.
Sentry SDKs allow you to configure a sample rate (example). The "Project" table in the "Usage Stats" tab of Stats can also help you make decisions about the sample rate that's most relevant for your usage.
Quotas can only be updated by a Billing or Owner member of your Sentry organization.
Once your span unit volume is approaching or has exceeded the quota, teammates with the "Owner" organization permission level will receive notification emails. You can then choose to increase or decrease your quota.
If you're dropping events that you want to keep because you've exceeded your quota, add to your quota at any time during your billing cycle by either increasing your reserved or pay-as-you-go quota.
When 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.
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'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 span units and purchase pay-as-you-go budget, as needed. Learn about Sentry's plans on our pricing page.
If you upgrade from Team to Business mid-billing period, your pay-as-you-go pricing changes retroactively.
If the number of events you need is steadily increasing, you may want to increase your reserved capacity or volume. Reserved volume is less expensive than pay-as-you-go volume since you prepay for it. It also allows you to choose the number of span units that you want to have available beforehand. Learn more about reserved volume in our pricing documentation.
You shouldn't increase your reserved volume if you think your need for more events is temporary, since reducing your reserved volume is tied to your billing period.
If you need to increase your span units quota temporarily, we recommend that you add or increase pay-as-you-go budget. This is ideal for situations like rolling out a new version of your application where you anticipate more events for the month. Learn more about pay-as-you-go in our pricing documentation.
Plan downgrades and decreases in reserved volume are processed at the end of your billing period, and remaining volume cannot be refunded. For example, if you have a monthly billing period that starts on the 5th of the month, and you decrease your reserved volume on June 20th, then this change will be processed on July 4th. Your billing period beginning on July 5th will reflect your new reserved volume.
If you have an annual billing period, plan downgrades and decreases in reserved volume go into effect at the beginning of your next billing year.
Changes to pay-as-you-go budget typically go into effect immediately and are guaranteed to go into effect within 24 hours. However, you can't decrease your pay-as-you-go budget to less than what you've consumed in the current period.
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 period. Depending on your time zone, in some cases, changes made on the last day of the billing period will not go into effect until the next billing period.
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.
Once applied, you can track the filtered events (numbers and cause) using the graph provided at the top of the "Inbound Filters" page.
Sentry provides several methods to filter all events and attachments server-side, which are applied before checking for potential rate limits. Inbound filters include:
- Common browser extension errors
- Events coming from
localhost - Known legacy browsers errors
- Known web crawlers
- Specific release versions of your code
- Certain IP addresses
The first four options above are settings that you simply toggle on or off. Setting the others is explained further below.
After these checks are processed, events and attachments that aren't dropped based on these filters count toward your quota. They're accepted into Sentry, where they're persisted and stored.
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.
This feature is available only if your organization is on a Business or Enterprise plan.
If you discover a problematic release causing excessive noise, Sentry supports ignoring all events and attachments from that release. Navigate to [Project] > Settings > Inbound Filters, then add the release to the "Releases" field.
Sentry SDKs send transactions, each of which contain an arbitrary number of spans. Some Sentry SDKs support the beforeSendTransaction callback method. Once implemented, this method is invoked when the SDK captures a transaction event, right before sending it to your Sentry account. Because it receives the transaction event object as a parameter, you can use it to modify the event's data or drop the event completely (by returning null) based on your custom logic and the data available on the event, such as tags, environment, release version, transaction name, and so on. Note that only transaction events pass through beforeSendTransaction. Error and message events have a separate method, beforeSend, which is supported in all SDKs. Learn more about both methods in Filtering Events.
When you configure your SDK, you can control the number of transactions and therefore, the number of spans that are sent to Sentry by setting the tracing options, including either setting a sample rate or providing a function for sampling. You can also set up custom instrumentation for tracing to capture certain types of transactions.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").