Weave Code
Opentelemetry Propagation Server Timing Laravel Package
open-telemetry/opentelemetry-propagation-server-timing
Propagates OpenTelemetry trace context through the Server-Timing HTTP header, helping PHP applications correlate backend traces with browser and frontend requests for simpler debugging and performance analysis.
[READONLY] TraceResponse propagator contrib module
Frequently asked questions about Opentelemetry Propagation Server Timing
- What does open-telemetry/opentelemetry-propagation-server-timing actually do?
- It is an OpenTelemetry PHP TextMapPropagator that writes W3C trace context into the Server-Timing HTTP response header. Browsers and RUM agents can then read the traceparent and tracestate values from PerformanceResourceTiming.serverTiming and join client-side timings to the server-side span that produced the response. It is a correlation layer, not a tracer: it adds no instrumentation, spans, or exporters of its own.
- Is this a Laravel package, or do I have to wire it up myself?
- It is not a Laravel package. It is a framework-agnostic OpenTelemetry PHP contrib propagator, so in Laravel you add a thin middleware that injects into an array carrier and copies the resulting values onto the Symfony or Illuminate response headers. You also need to register the propagator on your TracerProvider, usually in a service provider. Expect one dependency, one binding, one middleware, and a config flag rather than a drop-in package.
- How do I install open-telemetry/opentelemetry-propagation-server-timing with Composer?
- Install it with composer require open-telemetry/opentelemetry-propagation-server-timing and confirm the resolved version on Packagist before relying on it. Because the upstream repo is a low-traffic contrib mirror, check the composer.json constraints for PHP and open-telemetry/sdk compatibility rather than assuming they match your app. If no stable release fits, pin a specific commit or vendor the propagator class into your own codebase.
- Do I need the OpenTelemetry PHP SDK installed for this propagator to work?
- Yes. The propagator only serialises and parses context; without open-telemetry/sdk, a TracerProvider, and an exporter, there is no active span context to inject and the package delivers nothing. In Laravel that usually means open-telemetry/opentelemetry-auto-laravel or a hand-rolled middleware stack is already tracing requests. Deploy this last, after tracing is live, not as the first step of an observability rollout.
- Which Laravel and PHP versions are supported, and is the package actively maintained?
- There is no published constraint matrix in the overview, and the repo shows very low activity, so treat Laravel 10 and 11 on PHP 8.1 through 8.3 as the assumed baseline rather than a guarantee. The upstream is effectively single-maintainer, pre-1.0 community code with a readonly mirror, so plan to own the source rather than depend on timely fixes. Verify the composer.json and recent commits against your target PHP version before adopting it.
- How do I register the Server-Timing propagator in a Laravel application?
- Compose it in code rather than through environment variables, because standard OTel propagator env settings usually only accept built-ins such as tracecontext and baggage. Build a propagator chain that includes TraceContext, Baggage if needed, and the Server-Timing propagator, then pass it to your TracerProvider. Add a middleware that runs after the root span starts and before the response is sent, calls inject on an array carrier, and copies traceparent and tracestate onto the response headers.
- Does it implement extract as well as inject?
- According to the overview it does both: it injects traceparent and tracestate into response headers and extracts trace context from incoming Server-Timing headers. That means it can sit in a global propagator list without breaking inbound context, but confirm the behaviour in the actual source before relying on it. In most Laravel setups extraction from Server-Timing on the request is rarely needed, since browsers send traceparent via other mechanisms or not at all.
- Will this work with Laravel Octane and StreamedResponse?
- Propagators are stateless, so long-lived Octane workers are not a problem in themselves; the risk is middleware ordering and response handling. Streamed responses flush headers before your middleware runs if it is positioned after the streaming callback, so inject early and copy headers onto the response object before it is sent. Test explicitly under Octane and with streamed downloads, since the header can be silently absent with no error signal.
- Why is the Server-Timing header missing in Chrome DevTools?
- Common causes are CORS exposure rules, proxies, and caching. For cross-origin requests the browser only exposes Server-Timing when the response includes Timing-Allow-Origin, and some setups also need Access-Control-Expose-Headers. CDNs, reverse proxies, and app-level caches frequently strip or cache the header, and unsampled spans may produce no entry at all. Check the raw response with curl before assuming the propagator failed.
- Is it safe to expose traceparent in Server-Timing in production?
- Trace IDs are not secrets, but publishing them to unauthenticated clients makes it easier to correlate responses against your internal telemetry. Decide deliberately whether to emit in production, and limit emission to sampled spans so you do not leak identifiers for every request. Also cap the header size, especially if you combine it with Baggage, since Server-Timing entries are unbounded and large headers can be truncated or rejected by intermediaries.
Weaver
How can I help you explore Laravel packages today?