This article addresses some common questions regarding our migration away from Transactions into Spans.
Why are we deprecating the Transactions dataset?
We’re simplifying our tracing data model and preparing to support OTEL via OTLP in the future. In OTEL conventions, there is no separate concept of a “transaction” — all tracing data is represented as spans. A transaction is simply a service entry span or root span, based on conventions.
This shift also allows us to simplify our SDKs, which previously required developers to manage transaction lifecycles and handle limits on spans per transaction.
We’ve invested in ingesting, storing, and querying spans, making span data far more useful so we can meet your current needs — and much more. With these capabilities in place, we’re now streamlining the product by removing redundant datasets.
What additional benefits does using the Explore→Traces view provide to users?
Customers from all plans can freely query and aggregate their spans in Explore→Traces, You can freely compute any metric based on custom attributes you attach to your spans or transactions today. We will continue investing in this UX to provide more functionality that makes it easier to debug problems.
Additionally - We have extrapolation built in the Explore→Traces view, so even if you sample on the client side we can still extrapolate and show you reliable metrics. Please see our docs to learn more.
When will this deprecation take place?
This deprecation is likely to occur by Nov 2025, we will update our product messaging to reflect the exact date as details are confirmed.
What happens to my transactions-based alerts?
count() based alerts:
We are migrating alerts that use count(), and related functions failure_count(), sum(), count_if() , count_unique(), from transaction-based alerts to span-based alerts using a special compatibility mode. These alerts should continue to behave the same, without any updates on your part.
The next time you save these alerts, you will need to update thresholds to take into account sampling rate. Rather than alerting on the absolute count of spans, alerts are now based on the same sampling weight used in explore.
avg() and percentile-based alerts
These alerts will be migrated from transaction-based alerts to span-based alerts and should continue behaving similarly. No changes are required on your part.
If any action is required on your part, a message will be shown when editing alerts in Sentry.
What happens to my transactions based dashboard widgets and saved queries?
We will automatically migrate any dashboard widgets or saved queries built on the transactions dataset to the spans dataset. Please note this can lead to some shift in numbers since the spans dataset has extrapolation built in to account for your client side sample rates.
Before, if your client's sample rate was 10% and you sent 1000 spans, we would show you a count of 100. Now, the spans dataset takes sample rate into account and would show a value closer to 1000 [docs].
What if I find something missing in Explore→Traces compared to what I am used to in Discover?
Please open a GitHub issue with Explore as the Product Area label if you are finding your alerts behaving unexpectedly. You can also write to feedback-tracing@sentry.io.