Summary
React Native exposes a PerformanceObserver API that supports longtask entry types. We should add a new integration that uses this to detect and report JS thread long tasks independently of tracing.
Motivation
Customer request. They want visibility into JS thread blocking at scale across their fleet — frequency, duration, and the ability to filter by custom attributes (userId, orgId, etc). Current stall tracking only attaches measurements to active transactions, so it misses long tasks that happen outside traced operations.
Requirements
- Always-on reporting — must work independently of active traces/transactions, with a configurable sample rate
- Configurable threshold — default 50ms from RN is too low for mobile; allow users to set their own (e.g. 200ms)
- Emit as metrics — report long task occurrences and durations via
Sentry.metrics so they're queryable/aggregatable in Dashboards, with user-set tags for filtering
- Code origin (stretch) —
PerformanceObserver does not provide stack traces. Correlating with continuous profiling would be the path here, but depends on continuous profiling support landing first. Out of scope for v1.
Technical Notes
- RN's
PerformanceObserver.supportedEntryTypes includes longtask — need to verify minimum RN version
- Existing
stallTrackingIntegration uses a setTimeout-based watchdog for similar detection but is transaction-scoped. Consider whether to extend it or build a separate integration
- The JS SDK's browser long task instrumentation creates spans; our use case is different (metrics, not spans) since it needs to work outside transactions
Open Questions
- Should we also emit long tasks as standalone spans (not tied to a root transaction) or strictly as metrics?
- Should this replace or complement the existing stall tracking integration?
Summary
React Native exposes a
PerformanceObserverAPI that supportslongtaskentry types. We should add a new integration that uses this to detect and report JS thread long tasks independently of tracing.Motivation
Customer request. They want visibility into JS thread blocking at scale across their fleet — frequency, duration, and the ability to filter by custom attributes (userId, orgId, etc). Current stall tracking only attaches measurements to active transactions, so it misses long tasks that happen outside traced operations.
Requirements
Sentry.metricsso they're queryable/aggregatable in Dashboards, with user-set tags for filteringPerformanceObserverdoes not provide stack traces. Correlating with continuous profiling would be the path here, but depends on continuous profiling support landing first. Out of scope for v1.Technical Notes
PerformanceObserver.supportedEntryTypesincludeslongtask— need to verify minimum RN versionstallTrackingIntegrationuses asetTimeout-based watchdog for similar detection but is transaction-scoped. Consider whether to extend it or build a separate integrationOpen Questions