Skip to main content
Distributed tracing allows you to follow a single request as it flows through multiple services, providing end-to-end visibility into your application’s performance.

How Distributed Tracing Works

Distributed tracing connects spans across service boundaries by propagating trace context through HTTP headers:
  1. Service A starts a trace and adds trace headers to outgoing requests
  2. Service B continues the trace by reading the headers and creating child spans
  3. Service C continues the same trace, creating a complete picture
All spans share the same Trace ID, allowing Sentry to group them together.

Automatic Instrumentation

Sentry automatically propagates trace context for common HTTP clients:
Trace headers (sentry-trace and baggage) are automatically added to outgoing requests for services in your tracePropagationTargets.

Trace Propagation Targets

Control which requests include trace headers:

Default Behavior

By default, trace context is propagated to:
  • localhost (all ports)
  • Same-origin requests
Be careful with wildcards. Don’t propagate trace headers to third-party services unless necessary, as this could leak trace information.

Continuing Traces

Server-Side

Continue a trace from incoming request headers:

Client-Side

Continue a trace from meta tags (for server-side rendered apps):

Trace Headers

sentry-trace Header

Format: {trace_id}-{span_id}-{sampled}
  • trace_id: 32-character hex string
  • span_id: 16-character hex string
  • sampled: 1 (sampled) or 0 (not sampled)

baggage Header

Carries additional metadata:

Manual Propagation

Manually add trace headers to requests:

Cross-Service Example

Service A (Frontend)

Service B (Backend API)

Service C (Payment Service)

The result is a single trace showing:
  1. User click (Frontend)
  2. API request (Frontend → Backend)
  3. Save order (Backend)
  4. Payment request (Backend → Payment Service)
  5. Charge card (Payment Service)
  6. Record transaction (Payment Service)

Dynamic Sampling Context

Dynamic Sampling Context (DSC) carries metadata for sampling decisions:

Sampling Considerations

Head-Based Sampling

Sampling decision is made at the start of the trace:
All services must honor the sampling decision from the root:

Per-Service Sampling

Each service can make its own sampling decisions:
For consistent distributed traces, use head-based sampling (single decision at the root) rather than per-service sampling.

Debugging Distributed Traces

Check Trace Headers

Verify Trace Continuity

Best Practices

  1. Configure trace propagation targets: Only propagate to services you control
  2. Use consistent DSNs: Ensure all services send data to the same Sentry project (or linked projects)
  3. Honor parent sampling: Don’t override the sampling decision from the root
  4. Set meaningful operation names: Use standard operation types (http.server, http.client, etc.)
  5. Add service identifiers: Tag spans with service names for easy filtering
  6. Monitor trace completion: Ensure all services successfully propagate trace context

Common Pitfalls

Missing Trace Headers

Incorrect Trace Continuation

Next Steps

Tracing

Learn about traces and spans

Spans

Work with individual spans

Performance

Performance monitoring overview

Session Replay

Combine traces with session replay