Show specific transaction/span names being caught by inbound filters

[Kobby-Bawuah]

Problem Statement

When transactions or spans are filtered (e.g., by the "Filter out health check transactions" setting), users can only see aggregate counts by filter reason in the Data Filters chart. There's no way to see which specific transaction names are being filtered.

This makes it difficult to:

• Verify that the filter is correctly catching health checks (like /health, /ping) and not something else
• Debug cases where legitimate transactions might be incorrectly triggering a filter
• Understand why a large percentage of data is being filtered

Users have reported spending significant time debugging filtering issues because they can see "Filtered Transaction: 17,913" but have no visibility into what those 17,913 transactions actually are.

Solution Brainstorm

• Add a drill-down view from the Data Filters chart that shows a sample/list of filtered transaction names grouped by filter reason
• Add a "Filtered" tab or section in the Stats page that lists top transaction names being filtered
• Show recent examples of filtered transaction names in the filter settings UI so users can verify the filter is working as expected

Product Area

Settings

[linear]

ENG-6363

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

Routing to @getsentry/product-owners-ingestion-and-filtering for triage ⏲️

[jjbayer]

I believe there's an easy part to this and a hard part:

1. Improving the outcome reason from filtered-transaction to the pattern that was applied should be easy. We can migrate health check filters to generic inbound filters and use something like health-check-pattern:*heartbeat* as an outcome reason, which would still be low-cardinality.
2. Keeping track of discarded samples is a harder problem. After all, we discard these transactions because we don't want to store them. This would involve setting up a separate data channel to communicate discards from outer relays inwards, and some form of storage to hold them (redis?). I would advice against this because of the implied complexity.

Will discuss with the team if we can implement (1), or if a different team is better suited to make the changes.