Span Context Propagation
Span context propagation carries the trace and span IDs across process boundaries — HTTP headers, message metadata — so a trace that spans four services is one connected trace, not four orphan.
Definition
Span context propagation is the mechanism that serializes the trace context (trace ID, span ID, flags) into a carrier — W3C traceparent header, message metadata — at a process exit and deserializes it at the next process entry, so that the trace is a connected tree across every hop rather than a set of unlinked single-process traces.
Context and scope
Applied in distributed tracing, OpenTelemetry, and any system where a request crosses process boundaries and the trace must be reconstructed.
Common misconceptions
- Propagation is just passing headers — it is passing headers with a standard format and handling every hop, including async and message queues, which are easy to miss
- Async propagation is automatic — it is automatic in frameworks that instrument the runtime; in hand-rolled async, the context must be captured and restored manually
Anti-patterns
- Propagating across HTTP but not across the message queue, so the trace breaks at every async hop
- Using a non-standard propagation format that the downstream service does not parse, dropping the context silently
Related concepts
Authoritative source
What it is
Span context propagation is the mechanism that serializes the trace context (trace ID, span ID, flags) into a carrier — W3C traceparent header, message metadata — at a process exit and deserializes it at the next process entry, so that the trace is a connected tree across every hop rather than a set of unlinked single-process traces. Applied in distributed tracing, OpenTelemetry, and any system where a request crosses process boundaries and the trace must be reconstructed. The goal is not to collect all data but to be able to answer the question you did not think to ask in advance — which requires high-cardinality labels and exemplars that link traces to the metric that triggered them.
How it works
Three signals compose: metrics aggregate over time, traces preserve causality across boundaries, and logs carry the unstructured detail. Sampling is adaptive — head sampling for known-interesting paths, tail sampling to retain slow or error traces at a fixed budget. Cardinality is controlled at the source, not the query, because a high-cardinality label explodes storage and makes dashboards unusable.
When to invest and pitfalls
Invest when mean time to detect matters — in production, at scale, with paying users. The pitfall is instrumenting everything and alerting on nothing: dashboards full of lines that no one reads, alerts that fire on noise and are then muted, leaving the real outage undetected. Symptom-based alerts on user-visible degradation outperform cause-based alerts on internal thresholds.