Problem Statement
Context
The Sentry SDK already propagates the effective sampling rate as part of the Dynamic Sampling Context (DSC) via the W3C baggage header (sentry-sample_rate). However, this value is not surfaced as a queryable attribute in Sentry's span data model — meaning platform teams cannot audit or govern sampling configurations across projects without requiring each development team to manually add custom tags in their application code.
Problem Statement
In large organizations managing dozens or hundreds of Sentry projects, understanding the effective sampling rate applied by each team is critical for:
- Quota governance - identifying projects over-consuming span volume
- Signal quality auditing - detecting projects with sampling too low (blind spots) or too high (noise)
- Centralized observability - building dashboards without depending on per-team instrumentation discipline
Currently, the only way to infer sampling rates is by cross-referencing the Stats page (accepted vs. client-discarded spans), or by asking each team individually. Both approaches are manual, error-prone, and unscalable.
Proposed Solution
Since sentry-sample_rate is already present in the baggage header of every sampled trace envelope received by Sentry's ingest pipeline, we propose that Sentry automatically extract and index this value as a first-class span attribute - for example:
sampling.rate → e.g. 0.0001
sampling.mechanism → e.g. "tracesSampleRate" | "tracesSampler" | "parentSampled"This would enable platform/SRE teams to:
- Query spans filtered or grouped by
sampling.rate across all projects
- Build dashboards showing effective sampling distribution per project
- Set alerts when a project's effective sampling rate deviates from expected thresholds
- All of this without requiring any code changes from individual development teams
Why Now / Why This Approach
- The data already exists in the ingest pipeline - this is anextraction problem, not a collection problem
- It aligns with Sentry's direction toward Dynamic Sampling and quota management tooling
- It reduces the governance burden on platform teams in multi-project organizations
- It enables better collaboration between SDK authors and platform owners without friction
Alternatives Considered
- Custom tags per team: Works but requires code discipline across every project and team, which is unreliable at scale.
- Stats page inference (accepted ÷ total): Approximate and not actionable at the span/trace level.
- Sentry's Dynamic Sampling Rules UI: Controls server-side sampling but does not expose client-sidetracesSampleRateconfigured in the SDK.
Requested Outcome
Surface sentry-sample_rate (and ideally sentry-sampled) from the DSC baggage as indexed, queryable span attributes in Discover, the Spans dataset, and Stats - enabling central platform teams to audit and govern sampling configuration without modifying application code.
Solution Brainstorm
No response
Product Area
Unknown
Problem Statement
Context
The Sentry SDK already propagates the effective sampling rate as part of the Dynamic Sampling Context (DSC) via the W3C baggage header (sentry-sample_rate). However, this value is not surfaced as a queryable attribute in Sentry's span data model — meaning platform teams cannot audit or govern sampling configurations across projects without requiring each development team to manually add custom tags in their application code.
Problem Statement
In large organizations managing dozens or hundreds of Sentry projects, understanding the effective sampling rate applied by each team is critical for:
Currently, the only way to infer sampling rates is by cross-referencing the Stats page (accepted vs. client-discarded spans), or by asking each team individually. Both approaches are manual, error-prone, and unscalable.
Proposed Solution
Since
sentry-sample_rateis already present in the baggage header of every sampled trace envelope received by Sentry's ingest pipeline, we propose that Sentry automatically extract and index this value as a first-class span attribute - for example:sampling.rateacross all projectsWhy Now / Why This Approach
Alternatives Considered
Requested Outcome
Surface
sentry-sample_rate(and ideallysentry-sampled) from the DSC baggage as indexed, queryable span attributes in Discover, the Spans dataset, and Stats - enabling central platform teams to audit and govern sampling configuration without modifying application code.Solution Brainstorm
No response
Product Area
Unknown