Client Root Span

Problem

Some of your traces begin with a span of kind client that has no parent. A client span describes an outgoing call, so a trace starting there means whatever handled the incoming work never created a span: either the receiving service isn’t instrumented, or the trace context was lost on the way in.

Insights evaluates each span independently and flags root spans whose kind is client.

Impact

• Traces are incomplete: you see that a call was made, but not what handled it or how long the real work took.
• Latency breakdowns misattribute time; everything downstream of the gap is invisible.
• The gap usually hides exactly the service you’d want to debug.

Example

Trace starting mid-air:

trace 8f3c…
  └─ CLIENT POST /payments   ← root span, kind=client, no parent

Complete trace:

trace 8f3c…
  └─ SERVER POST /checkout
     └─ CLIENT POST /payments
        └─ SERVER POST /payments

How to fix

1. Identify the service making the flagged client call, then look one hop upstream: what received the request that triggered it? That component is missing instrumentation.
2. If both sides are instrumented, check context propagation: the traceparent header must be extracted on inbound requests and injected into outbound ones; middleware ordering and custom HTTP clients are the usual culprits.
3. Message queues and background jobs need explicit context passing; most instrumentation libraries provide helpers for it.

Expected gains

Traces run end to end, latency lands on the component that actually spent it, and the service that used to be a blind spot becomes debuggable.

See the Insights catalog for everything Insights can detect.