See the user behind every backend error.
When a backend service throws an exception, Traceway shows you the user's session replay, the cross-service trace, and the exact span that failed. No log-digging. No guessing what happened.
Trace requests across every service
Follow a single user action from the browser through your API gateway, backend services, and database calls. See the full picture in one distributed trace.
Every span. Every hop.
Visualize a request as a waterfall: each hop between services shows duration, status, and the exact span where latency or errors appear. Click any span to open its logs, exceptions, and attributes.
- Cross-service distributed trace propagation
- W3C Trace Context standard headers
- Drill-down to span attributes, logs, events
- Async workflows (Kafka, RabbitMQ, SQS)
See what the user did when the backend broke
Traceway connects frontend session replays to backend exceptions. When your payment service returns a 500, you don't just see the stack trace. You see the user clicking Checkout, filling in their card, and hitting submit.
- Frontend replay linked to backend errors
- Automatic correlation via trace ID
- No manual reproduction needed
- Works across browser and server
More than spans, full context
Source map stack trace resolution
Minified JavaScript stack traces are resolved to original source files and line numbers automatically. Upload your source maps and every frontend error shows readable, actionable traces. Works with webpack, esbuild, and Vite.
Impact propagation
The Impact Score extends across service boundaries. When an upstream service degrades, its impact propagates to every downstream consumer, so you fix the root cause, not the symptoms.
Trace every hop, not just the first.
Connect an SDK, propagate one trace ID, and see the whole story.
Questions about traces
How does distributed tracing work?
Traceway propagates a trace ID across every service in a request chain. The frontend SDK generates the ID and passes it to your backend via the traceparent header (W3C Trace Context). Each backend service forwards it to downstream calls. Every span, exception, and session replay recorded with that trace ID is linked together, giving you a complete picture of a single user action across your entire architecture.
Does Traceway connect frontend and backend issues?
Yes. When a backend service returns an error, Traceway links it to the frontend session replay that triggered the request. You see the user's clicks and navigations alongside the server-side stack trace and span waterfall. Both sides are connected automatically via the shared trace ID.
How does distributed tracing connect to session replay?
Traceway's frontend SDK generates a trace ID for each user interaction and passes it to your backend via the traceparent header. When the backend reports a span or exception with that trace ID, Traceway links the frontend session replay to the backend trace automatically.
What protocols does Traceway use for trace propagation?
Traceway supports W3C Trace Context (traceparent/tracestate headers) and is compatible with any OpenTelemetry-instrumented service. If your services already propagate trace context, Traceway picks it up automatically.
Do I need to instrument both frontend and backend?
For the full experience (session replay linked to backend traces), yes. The frontend SDK captures user interactions and the backend middleware captures server-side spans. Both connect via the shared trace ID. However, backend-only distributed tracing works independently.
Does distributed tracing work with message queues and async workflows?
Yes. Traceway uses W3C Trace Context, and OpenTelemetry instrumentation libraries for Kafka, RabbitMQ, SQS, and other message brokers propagate the trace context through message headers automatically. When a consumer processes a message, its spans are linked to the original producer's trace, so an API that publishes to Kafka, which triggers a worker, which calls a downstream service, appears as a single connected trace.