What changed
On August 18, Supabase documented end-to-end W3C Trace Context propagation from its client SDKs into API Gateway and Edge Function logs. The same announcement also says supabase-js versions 2.106.0 through 2.111.x silently sent no trace headers in bundled applications; users need 2.112.0 or later plus the tracing entry-point import for propagation to work correctly.
Why it matters
Crossing the frontend/backend boundary is a common observability blind spot in hosted application stacks. A shared trace_id lets builders correlate a slow browser request with the exact Supabase gateway or Edge Function log instead of lining up timestamps manually. The disclosed version gap is more consequential for teams that believed tracing was already enabled, because their telemetry may have been incomplete without an obvious runtime failure.
Client and Supabase logs can now share one trace identifier
When tracePropagation is enabled, supported Supabase clients attach the W3C traceparent, tracestate and baggage headers to requests sent to Supabase domains. Supabase carries that context into API Gateway and Edge Function logs, where the same trace_id can be joined with client-side spans in OpenTelemetry-compatible tools such as Sentry, Datadog, Honeycomb and Grafana.
The JavaScript rollout included a silent failure window
Supabase says supabase-js 2.106.0 through 2.111.x silently sent no trace headers in bundled apps. Builders who enabled trace propagation in those versions did not necessarily receive the telemetry they expected. The fix requires upgrading to 2.112.0 or later and importing @supabase/supabase-js/tracing at application startup.
The integration is opt-in and does not pull tracing code into every bundle
The main supabase-js bundle contains no OpenTelemetry runtime by default. The tracing integration lives behind a separate entry point, so teams that do not enable it do not pay the bundle or dependency cost. Applications still need their own tracer and an active span; Supabase does not configure an OpenTelemetry provider automatically.
Coverage is useful but not universal
Trace propagation currently targets Supabase project domains and local development hosts, not arbitrary third-party requests. On the server side, the shared trace_id is currently added to API Gateway and Edge Function logs. CDN/UMD builds are not supported, while Supabase says equivalent propagation is available in Swift, Flutter and Python clients.