Alert condition for "percent of sessions on a particular version affected by an issue"

[damianw]

Problem Statement

Currently, Sentry has several options for alert triggering conditions based on issue frequency:

While the "percent of sessions affected by an issue" option is helpful for alerts intending to detect widespread issues, it is not particularly helpful for detecting issues which occur solely on versions with low widespread adoption, which is a common scenario for frontend applications.

Two common scenarios are:

• A backend change is deployed that affects only some newer or older versions of a frontend application.
• During the roll-out of a new version of a frontend application, the new version may have a critical issue which triggers a significant number of events relative to the number of sessions on that version, but the number of sessions on that version is small relative to the total number of sessions.

For example, if 99% of users are on version 1.0 and 1% are on version 2.0, and issue X affects 99% of sessions on version 2.0, there is no way to write a rule that informs engineers about the critical issue on version 2.0. The closest would be "number of sessions affected by an issue is > 1% of total sessions", but that wouldn't trigger in this example, because it uses the total number of sessions.

Solution Brainstorm

An option for "percent of sessions on a particular version affected by an issue" would completely solve this issue. This is the way that Velocity Alerts on Firebase Crashlytics work -- and even though their alerting system is much less flexible (this is the only type of alert), it is much more valuable on account of the way they compute affected sessions.

Product Area

Alerts

[getsantry[bot]]

Assigning to @getsentry/support for routing ⏲️

[getsantry[bot]]

Routing to @getsentry/product-owners-alerts for triage ⏲️

[leedongwei]

Hey! Thanks for the feedback!

We have a product specs in the draft stage to address this issue. The idea is that we'll allow an alert to be monitored by grouping unique values in a tag field (which can be release versions). Currently looking to start work on it in Q1.