Search any span.
Follow the whole trace.
Find the slow query, failed request or background job. Open its trace to see the services involved, where the time went, and what the logs say—all connected by the original OpenTelemetry trace ID.
Start with the operation that needs attention.
Filter by service, name, kind, status, duration, trace ID or an exact attribute value. Open a result to see where it belongs in the request.
Captured in Traceway · checkout demo data
Keep the context your tools already send.
Send traces from your existing OpenTelemetry SDK or Collector over OTLP/HTTP. Your services keep their trace IDs, span IDs and parent relationships.
Search beyond HTTP
Database calls, internal operations, producers and consumers are all searchable spans. Filter the work itself, even when it has no endpoint or task page.
Follow service boundaries
See one trace across services and the projects you can access in your organization. Expand branches, spot errors and jump straight to a selected span.
Preserve the OTel detail
Original OTLP payloads retain typed attributes, resource and scope metadata, events and span links. Retrieve a stored span through the OTLP export API when you need its full payload.
The request failed. Here is what it logged.
Read logs carrying the same trace ID alongside the waterfall. See the emitting service and span, then expand a record for its attributes. Logs stay scoped to the selected project.
From the browser to the backend.
The Traceway browser SDK propagates W3C trace context on configured requests. When your backend instrumentation continues that context, captured errors and sessions can carry the same trace ID. Add session replay to see what the user was doing alongside the technical context.
Set up browser-to-backend tracingQuestions about tracing
Can I use my existing OpenTelemetry instrumentation?
Yes. Send traces with an OpenTelemetry SDK or Collector using OTLP over HTTP, in protobuf or JSON format. Traceway keeps the original trace and span IDs. Backend tracing works independently of the Traceway browser SDK.
What can I search in the span explorer?
Search received spans by name, service, span kind, status, minimum or maximum duration, trace ID and exact attribute values within a time range. HTTP calls, database queries, internal spans and messaging operations are all available. Open a result to view its trace with that span selected.
How are spans connected across services?
Your instrumentation propagates W3C trace context between services. Spans in the same trace share a trace ID, and parent span IDs describe their relationships. Traceway assembles that trace across the projects you can access in the selected organization.
Are span links the same as parent-child relationships?
No. OpenTelemetry span links can reference spans in the same trace or a different trace, for example in a batch or asynchronous workflow. Traceway preserves those links in the original OTLP payload and export. They do not merge separate traces into one waterfall. Whether a queue consumer continues a trace or links to it depends on your instrumentation.
How do logs connect to a trace?
Export logs with a trace ID and, when available, a span ID. The trace page shows matching logs in the selected project and surrounding time window, with their service and span names. A span ID lets you narrow a log search to a specific operation.
Can I connect browser errors and session replay?
Yes. Configure W3C propagation in the Traceway browser SDK and context extraction in your backend instrumentation. Errors and sessions carrying that trace ID can be correlated with the backend trace. For cross-origin requests, allow the destination in the SDK and permit traceparent and tracestate in your server's CORS policy.
Bring your spans. See the request.
Connect your OpenTelemetry exporter and start with the span explorer.