Retention Priorities
Retention priorities are only available on the latest version of our plans, starting from 1M reserved transactions. Anyone in your org with owner or billing-level permissions can update your plan by going to Settings > Subscription, and clicking the "Manage Subscription" button.
While storing all your data makes sense at relatively low volumes, as your application scales, storing a raw copy of all your data has diminishing returns. When data reaches high volumes, Sentry begins to automatically prioritize retaining certain transactions over others with server-side data retention strategies called retention priorities.
It's important to note that even when we begin to only store the most valuable data based on retention priorities, the performance metrics you see are still based on all the events you send to Sentry. This ensures that you get a full and complete view of your application's health.
Prerequisites
- Admin-level permissions.
- Latest version of one of the below SDKs:
- Python: 1.7.2 or later
- JavaScript: 7.6.0 or later
- Apple: 7.23.0 or later
- Android: 6.5.0 or later
- React Native: 4.3.0 or later
- Dart and Flutter: 6.11.0 or later
- PHP: 3.9.0 or later
- Laravel: 3.0.0 or later
- Symfony: 4.4.0 or later
- Ruby: 5.5.0 or later
- Java: 6.5.0 or later
- .NET: 3.22.0 or later
- Go: 0.16.0 or later
Retention Priorities
Below is a list of the transactions we prioritize and deprioritize. They are enabled by default, but can be updated on a per-
Prioritized Transactions
Sentry automatically prioritizes and retains the following types of transactions:
Latest Release
Latest releases are a retention priority because when you create a new release, we assume you'll want to have more visibility during the early adoption phase, which improves your ability to catch new issues as your release is gaining traction. Because you may want to deploy the same release in different environments, we'll also take your environment into account and prioritize those transactions.
Dev Environments
Since dev environments usually generate a small number of transactions as compared to prod environments, we prioritize them during your testing phase so you can get meaningful insights. We consider an environment to be a dev environment if its name matches one of the following glob pattterns:
*debug*
*dev*
*local*
*qa*
*test*
Low Volume Projects
You won't be able to disable the Low Volume Projects retention priority because it's set on an organization-wide level, not on a per-
Some projects within your organization are very high volume compared to others. This means that low-volume projects might get drowned out if we treat all projects equally. To ensure that you have enough samples regardless of project scale, we prioritize low-volume projects.
Low Volume Transactions
Transactions can be logically grouped by their name within a
Deprioritized Transactions
Sentry automatically deprioritizes the following transactions:
Health Checks
We deprioritize health check type transactions because while they're important for checking the stability of your application, they don't have any value beyond the task associated with them. We consider a transaction to be a health check if its name matches one of the following glob patterns:
*healthcheck*
*heartbeat*
*/health
*/healthy
*/healthz
*/live
*/livez
*/ready
*/readyz
*/ping
How to Change Retention Priorities
To make changes to a
Deciding on Your SDK Sample Rate
To give Sentry the fullest, most accurate picture of your application’s health, we recommend that you send us 100% of your transactions. You can do this by setting your tracesSampleRate to 1.0. If this isn't feasible for your organization, set a lower value, or switch to sampling selectively by using the tracesSampler to filter your transactions based on contextual data. Note that when calculating throughput, transaction metering is based on received transactions not stored transactions.
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").