We're expecting to see performance regression issues for a specific transaction, but none are being generated even though we notice slower transaction durations.

​

Sentry’s performance issue detector analyzes the 95th percentile transaction duration of the most common endpoints in your project. Only transactions that meet certain thresholds - specifically being among the most common endpoints and having at least 50 events per hour - are eligible for regression detection.

If a transaction falls below these thresholds, it’s considered low throughput, and regression issues will not be created. The regression detection process uses a two-stage pipeline: first, trend detection identifies potential regressions in real time based on a 200 ms minimum change, 15 % relative change, and 18+ data points, then, breakpoint confirmation runs about 12 hours later to verify significance using statistical tests over three days of data.
​
You can review the implementation details in Sentry’s open-source code: EndpointRegressionDetector + detector_algorithm_factory and Breakpoint confirmation logic.
​

In short, if your transaction doesn’t meet the event volume or endpoint frequency criteria, it won’t trigger regression issues until sufficient data is available.