Orphaned Spans

Problem

Some spans reference a parent_span_id that never arrived in the same trace. An orphaned span almost always means broken trace-context propagation, missing instrumentation, or sampling and export loss, and it points at the exact seam between two services where your traces break.

Insights waits a short settling window (five minutes) for each trace to fully arrive before judging, so slow spans aren’t mistaken for orphans.

Impact

• Traces render as disconnected fragments instead of one request story.
• Timing gaps appear where the missing parent should be, so latency analysis misleads.
• The break sits precisely between two services, the place where debugging cross-service issues needs traces the most.

Example

Fragmented:

trace 4a1b…
  (missing parent)
     └─ SERVER POST /payments   ← parent_span_id points to a span
                                  that never arrived

Connected:

trace 4a1b…
  └─ SERVER POST /checkout
     └─ CLIENT POST /payments
        └─ SERVER POST /payments

How to fix

1. Identify the two services at the seam: the orphaned span’s service, and the upstream service that should have emitted its parent.
2. If the upstream span is never created, instrument that hop (middleware or client wrapper).
3. If it’s created but missing, check sampling and export: a head-sampling decision or a dropped batch upstream deletes parents while children survive. Align sampling decisions across services.

Expected gains

Traces connect end to end, latency attribution becomes trustworthy, and the cross-service seams stop being blind spots.

See the Insights catalog for everything Insights can detect.