Key details

  1. Published August 18, 2026.
  2. supabase-js can propagate W3C traceparent, tracestate and baggage headers to Supabase requests.
  3. Supabase API Gateway and Edge Function logs can carry the same trace_id as the originating client trace.
  4. The feature interoperates with W3C-compatible tracing systems including OpenTelemetry-based tooling.
  5. supabase-js versions 2.106.0 through 2.111.x silently failed to send trace headers in bundled apps.
  6. JavaScript users should upgrade to supabase-js 2.112.0 or later and import @supabase/supabase-js/tracing.
  7. Trace propagation is opt-in and requires an active span and configured tracing provider.
  8. The default behavior respects the tracer's sampling decision, though builders can override that for Supabase requests.
  9. The tracing runtime is excluded from the main supabase-js bundle unless explicitly imported.
  10. Current server-side coverage is limited to API Gateway and Edge Function logs.

What builders should take away

  1. If you enabled Supabase tracing on supabase-js 2.106.0–2.111.x, treat your historical telemetry as potentially incomplete and upgrade to 2.112.0 or later before relying on trace continuity.
  2. Add the explicit @supabase/supabase-js/tracing import at application startup; enabling tracePropagation alone is not sufficient on current versions.
  3. Use the shared trace_id in Log Drains or your existing observability backend to correlate browser latency with Supabase gateway or Edge Function behavior.
  4. Verify that requests run inside an active span and that a real TracerProvider is registered, because the SDK silently no-ops when there is no trace context to propagate.
  5. Review sampling settings if low sampling rates would make backend correlation too sparse; Supabase supports overriding the default respect-for-sampling behavior.

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.

Timeline

2026-08-18

Supabase documents trace propagation and JavaScript fix

Supabase announced W3C Trace Context propagation into backend logs and told JavaScript users to upgrade past versions that silently failed to emit headers in bundled apps.

What to watch next

  • Whether Supabase extends trace_id propagation beyond API Gateway and Edge Function logs to database, Auth, Storage and Realtime logs.
  • Whether the tracing entry point becomes unnecessary in a future supabase-js release.
  • Whether Supabase publishes a formal incident or changelog entry explaining the 2.106.0–2.111.x propagation failure and its root cause.
  • Whether CDN/UMD builds gain tracing support.

Still unclear

  • Supabase's post documents the affected supabase-js version range and required upgrade but does not provide a root-cause analysis or quantify how many applications were affected.
  • The announcement does not specify when trace propagation first became available in the non-JavaScript SDKs.

Sources

Direct reading behind this dossier.

1 sources
Connect client traces to your logs
Supabase official blog

Primary source for W3C Trace Context behavior, supported SDKs and log sources, opt-in setup, limitations, and the 2.106.0–2.111.x silent propagation failure.