Dynamic Sampling

Just because you don’t record a problem, that doesn’t mean it didn’t happen. Sentry's Dynamic Sampling feature ensures that you get complete insight into the performance of your application in a way that scales affordably with your traffic, so you never miss a critical issue. With dynamic sampling, we can maximize the value from your performance data as you scale, without you having to manage complex sampling rules.

We do this by automatically prioritizing your transactions, server-side, so that we can provide you with the most valuable and accurate insights about your application’s performance while also applying helpful prioritization to the data we retain for you.

While we do our best to provide you with the most useful transaction data, our Dynamic Sampling feature allows you to turn the priorities that we apply to your data retention on or off. By default, these toggles are all enabled so that Sentry's dynamic sampling priorities are applied to your data:

The Dynamic Sampling page with priority toggles enabled.

Because every project is different, you can set these toggles differently for different projects. For example, you may have a project where retaining transactions from the latest release is not a priority for you.

Data Retention Priorities

When your data reaches high volumes, Sentry begins to automatically prioritize your transactions, server-side. By default, we prioritize transaction data in the following ways:

PrioritizeIgnore
Latest ReleaseHealth Checks
Dev Environments
Starred Transactions

Latest Release

When you create a new release, you'll likely want to have more visibility during the early adoption phase. To improve your ability to catch new issues as soon as your release is being adopted, we prioritize data from the latest release.

While prioritizing data from the latest release, we also take into consideration your environment because you might deploy the same release in different environments. If we see this, we'll assume you want to have more visibility for those transactions as well.

Dev Environments

We prioritize data from development environments because these environments typically generate a relatively small number of transactions compared to your production environments. As a result, to gain meaningful insights during your testing phase, we prioritize transaction data from these environments.

Starred Transactions

Typically, for most projects there are only a few transactions that you really care about. We prioritize starred transactions over others, so you can have more visibility into your important data.

Health Checks

Health check type transactions, while important for checking the stability of your application, don't have any value for you beyond the task associated with them. They also tend to be high in volume, potentially using up a lot of you

quotaThe monthly number of events that you pay Sentry to track.
if retained. To avoid using up your volume on this type of transactions, we ignore these when sampling your data.

Dynamic Sampling & SDK Sampling

Dynamic sampling and your SDK sampling configuration act independently of each other, but our dynamic sampling works best when you send us as much data as you can. The more complete a picture of your application we have, the more accurately we can monitor your application health, detect problems faster, surface issues, and make better decisions about data retention on your behalf.

If it's feasible, send us 100% of your data (that is, set your tracesSampleRate in the SDK to 1.0). If you can't do so initially, the system will operate on what it can see and when you purchase more transaction volume, we'll adapt automatically. As a bonus, your per-transaction pricing goes down accordingly. Learn more in Benefits of Dynamic Sampling.

Next Steps

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