Docs

Sentry Feature Flag Context: Track the Flag Behind an Error

Sentry now shows which feature flags were active when an error fired, via LaunchDarkly and OpenFeature — what to instrument to make the link reliable.

Performance

Sentry has added feature flag context to issue details, capturing the flag evaluations active in the moments before an error and displaying them chronologically on the Issue Details page. It’s powered by integrations with LaunchDarkly and OpenFeature, has landed for Python and JavaScript projects, and the Cocoa SDK’s own flag support now records the last 100 flag evaluations leading up to a crash. The pitch is straightforward: instead of asking “did the flag rollout we shipped Tuesday cause this spike,” you open the issue and see the exact flag state at the moment it happened.

That’s a real improvement over the status quo, which for most teams is correlating a crash-rate graph against a rollout changelog by eye and hoping the timestamps line up closely enough to mean something. But the feature is only as good as flag evaluation coverage: it can only show flags that were actually evaluated through a tracked SDK call in that session, not every flag technically active for the user. A flag read once at app launch and cached in memory won’t show up as re-evaluated later, so an error three screens into a session may report a flag state that’s technically true but was captured well before the crash, not tied tightly to it. Teams that treat the flag list as a complete causal explanation rather than a lead will occasionally chase the wrong flag.

Data Points to Track

  • Flag evaluation count per error-adjacent session, to spot sessions where few or no flags were captured because evaluations happened before Sentry started tracking them
  • Time gap between last flag evaluation and error timestamp, since a large gap weakens the causal read even when a flag shows up in the context
  • Rollout percentage and cohort at time of error, cross-referenced against the flag provider’s own rollout log rather than trusted from Sentry’s snapshot alone
  • Error rate segmented by flag variant, tracked as an ongoing metric rather than only pulled up reactively after a spike
  • Flags evaluated but not displayed, checked periodically against your provider’s full flag list to confirm integration coverage isn’t silently dropping flags

Setup Steps

  1. Confirm the LaunchDarkly or OpenFeature integration is active for every project where flag-driven regressions are a real risk, not just the ones that have had an incident.
  2. Re-evaluate long-lived flags on a cadence within each session, rather than only at launch, so flag context captured near an error reflects current state.
  3. Cross-link Sentry’s flag context with your rollout dashboard, so a spike can be checked against both systems rather than Sentry’s context alone.
  4. Set an alert on error-rate divergence by flag variant, not just an alert on a flag’s own crash-free-session metric, since a variant can quietly degrade one journey while looking fine in aggregate.
  5. Audit flag evaluation coverage quarterly against your provider’s full flag list to catch flags that never register in Sentry’s context.

Actionable Insights

The time-gap figure is the one to check before trusting a flag correlation: a short gap between the last evaluation and the error is a strong causal signal, a long one is a coincidence dressed as an explanation. Once re-evaluation cadence and coverage are solid, the error-rate-by-variant view turns feature flag rollouts from a one-way ship into something with a live, per-cohort rollback trigger — catching a bad variant from its error signature instead of from support tickets.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert