Crash-free session and user metrics should break down by environment and release rather than requiring project separation

Problem Statement

Teams that want crash-free rate segmented by build type, platform, or deployment
stage end up creating a separate Sentry project per segment, because that is the
level at which the metric is reliably reported and compared.

This pushes a data-model concern into the project structure, and it has real costs.
Symbols, alert rules, ownership rules, integrations, and grouping configuration all
have to be duplicated per project and kept in sync, and they drift. Cross-segment
comparison gets harder rather than easier, because the segments now live in
different projects.

Environment and release already exist as the intended dimensions for exactly this
kind of segmentation. Teams that have correctly modelled their builds as
environments and releases are currently penalised relative to teams that split by
project, which is the wrong incentive.

Release health comparison across environments, internal build versus public build or
one platform versus another, is the primary question during a rollout, and it is the
hardest one to answer today.

Solution Brainstorm

• Support environment and release as filter and group-by dimensions on crash-free
  session and crash-free user metrics, in release health views and in dashboards.
• Allow alerting on crash-free rate scoped to a specific environment, so a
  regression in one build type can page without the others diluting the signal.
• Document the recommended modelling, so teams do not default to project splitting
  and then discover the cost later.

Product Area

Releases

Requested by Saad Khan.

--

View Junior Session [Sentry]

No files or tests are named in the issue. Start by tracing the release health views and crash-free session/user metric entry points, then inspect how dashboards and environment-scoped alerting are connected. Done means environment and release can filter and group these metrics, alerts can target an environment, and the recommended modeling is documented.