Skip to main content
Span timings are the core building block of distributed traces. They record when an operation began (start time), when it finished (end time), and the elapsed time between those points (duration). These values let you analyze latency, order operations, and detect bottlenecks across services.
  • Start time: the instant the operation began (e.g., just before sending a request).
  • End time: the instant the operation finished (e.g., after receiving an HTTP response).
  • Duration: end_time - start_time — the elapsed time or latency for the operation.
Below is a representative OpenTelemetry span showing start and end timestamps (microsecond precision in this example) along with several in-span events:
OpenTelemetry SDKs commonly support nanosecond precision; the exact timestamp representation varies by language and export format. The timestamps above use ISO 8601 with a Z suffix (UTC). Depending on SDK/export, timestamps may be encoded as RFC 3339/ISO 8601 strings or as epoch-based numeric fields (for example, time_unix_nano in OTLP protobuf). Here are the start and end fields shown again for clarity:
A compact summary:
FieldDefinitionExample
Start timeWhen the span operation began2025-10-17T12:57:33.567131Z
End timeWhen the span operation completed2025-10-17T12:57:53.210426Z
Durationend_time - start_time (elapsed time)19.643295 s
From the example timestamps we calculate:
  • start: 2025-10-17T12:57:33.567131Z
  • end: 2025-10-17T12:57:53.210426Z
  • duration: 19.643295 seconds (≈ 19.64 s)
Note that many backends and processing layers compute duration from the start and end timestamps rather than storing it as a separate span attribute in the payload.
Timestamps can be exported as RFC 3339/ISO 8601 strings or as epoch numeric fields (for example, time_unix_nano in OTLP protobuf). SDKs often provide microsecond or nanosecond precision, and observability backends derive duration from the recorded start and end times.
Span events: pinpointing moments inside a span
  • Span timings describe the overall operation window. Inside that window, span events capture notable instants — for example:
    • cache miss or cache hit
    • start of a retry
    • receiving an external API response
    • recording an exception or stack trace
  • In the JSON example above, three events are timestamped within the span. These events provide context that helps explain why the span took a given amount of time when you correlate them with logs, metrics, or traces.
Why accurate timings matter
  • Timings drive the trace timeline and waterfall visualizations used in APM/observability UIs.
  • Precise timestamps enable:
    • latency breakdowns (client → server → DB)
    • detection of ordering issues or clock skew
    • performance comparisons across releases and environments
References

Watch Video