Understanding Trace Sampling, Data Retention, and Visibility in Sentry.io
Sentry.io employs a two-tier data retention model for spans and transactions, which impacts trace visibility and query results. This article explains how trace sampling and data retention work, their effects on visibility, and how to troubleshoot related issues.
Data Retention and Sampling Policies
Sentry.io retains data differently based on the time period (this applies to Business and Enterprise plans. Developer and Team plans keep spans for 30 days with no sampled tier, and Team or Business plans on transaction-based billing keep transactions for 90 days with no sampled tier):
Full Fidelity (Up to 30 Days): All span and transaction events are retained at full fidelity, ensuring full visibility into everything that was ingested (SDK sample rates and Dynamic Sampling still apply before data is stored).
Sampled Data (Beyond 30 Days, Up to 13 Months): Data is downsampled, meaning only a subset of spans and transactions is retained. This sampling reduces the granularity of data available for queries beyond the 30-day window.
Impact on Trace Explorer and Query Results
In Trace Explorer, the maximum lookback period for full-fidelity data is 30 days. When extending the query window beyond 30 days (for example, to 90 days), the results are based on sampled data. This can lead to discrepancies where specific transactions visible in the 30-day view may not appear in the 90-day view due to sampling. While data exists in sampled form, it may seem like "nothing" is there because of the reduced visibility.
Specific Use Cases
Web Vitals Trends
Web vitals trend queries (e.g., LCP, CLS, INP) remain functional even after 30 days. This is because vital observations are stored on standalone spans or as measurements on the page-load span, depending on your configuration. These attributes allow for aggregation and trend analysis, even though full coherent traces are not guaranteed beyond 30 days due to per-span downsampling.
Uptime Monitor Behavior
If your Uptime Monitor appears empty with no traces, consider the following:
Each Uptime check should generate at least one uptime.request root span, even without SDK integration.
Common causes for missing traces include: data not reaching Sentry, and deactivated monitors (often due to exceeding your pay-as-you-go budget).
To resolve this:
Check if your monitor has been deactivated. Manually reactivating monitor first reuses quota already billed for that monitor type in the current billing period. Otherwise it draws on your reserved quota or pay-as-you-go budget, so it only succeeds if budget is available.
Increase your pay-as-you-go budget or reduce the number of monitors to stay within your plan limits.
Enable budget-usage notification emails to receive alerts as you approach or exceed your budget.
Best Practices for Managing Sampling and Retention
Plan for Sampling: Understand that data beyond 30 days is sampled and may not provide full trace visibility.
Monitor Budgets: Regularly review your pay-as-you-go budget to avoid unexpected deactivations of monitors.
Enable Notifications: Use budget-usage notifications to stay informed about your resource usage.
Optimize Queries: When querying data beyond 30 days, adjust expectations for granularity and completeness.
By understanding Sentry.io’s data retention and sampling policies, you can better manage trace visibility and troubleshoot issues effectively.