Glossary · Monitoring

Distributed Tracing

Distributed tracing follows a single request across multiple services, recording timed spans so you can see where latency or errors occur.

Updated October 6, 2026

Distributed tracing records the path of one request as it passes through many services. Each unit of work is a span with a start time, duration and metadata, and the spans of one request share a trace ID so they can be assembled into a tree.

Why it matters

In a microservice architecture a single page view may touch a dozen services, databases and third-party APIs. Metrics show that the whole request is slow, and logs from each service are scattered. A trace shows exactly which hop consumed the time, which calls ran in sequence instead of parallel, and where an error originated. A trace is the third classic telemetry signal alongside metrics and logs.

Example

A trace for GET /checkout taking 1,900 ms might look like:

checkout-api        1900 ms
  cart-service       120 ms
  inventory-service  240 ms
  payment-gateway   1450 ms   <- slow span

The slow span points to the payment call. Context travels between services in a header, such as the W3C traceparent header.

Common mistakes

  • Failing to propagate the trace header through one service, which splits the trace in two.
  • Sampling too aggressively and missing rare slow requests. Consider keeping all errors and slow traces.
  • Leaving out database and outbound HTTP calls from instrumentation.

Get notified when this term updates

Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.