Distributed tracing in Laravel

A technique for following a single user request as it hops across multiple services or processes. Every service adds a span to a shared trace ID passed in request headers. The resulting trace shows you, end-to-end, how long each service took — which is invaluable in microservices and useless overkill for a Laravel monolith.

Only if your system crosses service boundaries. If you're one Laravel monolith talking to a database and a couple of external APIs, per-request tracing (what NightOwl and Nightwatch Cloud provide) covers the same ground. If you have a Laravel API, a Node.js WebSocket server, a Python ML service, and a Go background worker all serving one user journey, distributed tracing is worth the setup cost.

Usually via OpenTelemetry. The OTel PHP SDK instruments your Laravel app to emit spans, and propagates a W3C traceparent header on outbound HTTP calls. Downstream services (also instrumented with OTel) extract the header and continue the trace. All services ship spans to an OTel Collector, which forwards them to a backend like Grafana Tempo, Jaeger, or a SaaS APM.

Distributed tracing is one capability inside the broader APM category. Traditional APMs (New Relic, Sentry) bundle it with error tracking, metrics, and dashboards. Modern observability stacks (OpenTelemetry + Grafana) separate concerns — tracing is its own product. Both camps ultimately show you the same thing: a flame-graph view of a single request across services.

A trace is the entire request's journey across services — a tree of spans sharing one trace ID. A span is one unit of work within the trace — an HTTP call, a DB query, a computation. Spans have parent/child relationships that reconstruct the tree. A span's duration plus its parent-child pointers are what let you render the familiar waterfall diagram.

Partially. The Nightwatch package records per-request traces within one Laravel app — every query, job, cache call, and outgoing HTTP span is tied to the originating request. It doesn't propagate trace context across services by default, so multi-service traces require adding OpenTelemetry on top. For a Laravel-only monolith, Nightwatch's per-request data is sufficient.

Usually not. The operational cost of running an OTel Collector, trace backend (Tempo/Jaeger), and instrumenting every service adds up. Small teams benefit more from a focused APM on each service that speaks its language natively. Adopt distributed tracing when you've actually hit the problem it solves — requests that cross services and where you can't tell which service is slow.