W3C tracecontext propagation across every SDK and every outbound request. Span trees, timing waterfalls, service maps. Pivot from any error to the full trace that produced it.
Each SDK auto-instruments outbound HTTP and database calls (where the framework allows). Every span gets a trace_id, a span_id, optional parent_id, free-form attributes, and a list of events. The wire format is OTLP-compatible.
W3C tracecontext is sent on every outbound request the SDK can intercept (fetch, undici, axios, requests, httpx, net/http). Receiving services pick it up via the framework middleware and continue the trace under the same trace_id. A request that crosses three services produces three spans in one trace.
Click any trace_id in the dashboard to see the full waterfall. Spans are grouped by service, color-coded, with duration bars on the timeline. Click a span to see attributes, events, and any errors that occurred inside it.
Errors that occur during a request are stamped with the active trace_id and span_id. From any error in the issue list, you can pivot to the full trace and see what happened upstream and downstream. From a trace, you can see all events that fired during it.
The dashboard derives a service map from the spans seen in the last hour. Nodes are services; edges are inter-service request volume. Click an edge to see the spans flowing between two services. v0.5 for richer rendering.
Trace sample rate is independent from error sample rate. Default is tracesSampleRate: 0.0 — opt in by setting it to 0.1 to 1.0 in your SDK init. When the project is over its trace quota, adaptive sampling kicks in automatically (errors stay at 100%).
The ingest API exposes /v1/otlp/traces as an OTLP endpoint, so anything that already speaks OTLP (the OTel Collector, the OTel SDKs in any language) can ship to CodeRadar without using ours. The trace tree renders identically.