Span

What it means

A span records one operation and how long it took - the start time, the end time, and any metadata attached to it. In an LLM application a span might wrap a single model call, a vector-store lookup, a function or tool call, or a guardrail check. Each span carries attributes such as the model name, token counts, latency, cost, and the input and output payloads. Spans link to a parent span, which is how a tree of work forms under one trace.

Why it matters

When an LLM request is slow, expensive, or wrong, the failure almost never lives in the request as a whole - it lives in one step. Spans give you that resolution. You can see that retrieval returned poor context, that a tool call timed out, or that one model call burned most of the token budget. Without spans you only know the final answer was bad. With them you know exactly which stage to fix. Spans are also the unit that cost and latency dashboards aggregate over, so accurate span data is the foundation of any usage or spend analysis.

In practice

Most LLM observability platforms follow the OpenTelemetry data model, where a trace is a tree of spans. Tools like Langfuse and LangSmith auto-instrument popular SDKs so that each model call, chain step, and tool invocation becomes a span with no manual wiring. You can also create spans by hand to wrap custom logic - for example, a preprocessing step or a business rule - so it shows up alongside the model calls in the same timeline. Reading a trace top to bottom then becomes a matter of scanning its spans for the one with high latency, a large token count, or an unexpected output.