🚨 OpenTelemetry Error Guide: 'context deadline exceeded' — Fix Exporter Timeouts

Overview

This error appears when an OpenTelemetry exporter cannot complete an OTLP export before its deadline elapses. It surfaces in SDK logs and in the Collector’s own otlp exporter:

2026-07-09T14:22:10.114Z	error	exporterhelper/queue_sender.go:128	Exporting failed. Dropping data.	{"kind": "exporter", "data_type": "traces", "name": "otlp", "error": "context deadline exceeded", "dropped_items": 512}

The gRPC transport variant carries a status code:

rpc error: code = DeadlineExceeded desc = context deadline exceeded

context deadline exceeded is Go’s context.DeadlineExceeded: the export call ran longer than the configured timeout (default 5s for OTLP) and was cancelled. Data that could not be delivered within the deadline is retried or dropped.

Symptoms

• Traces, metrics, or logs arrive intermittently or not at all in your backend.
• SDK stderr shows traces export: context deadline exceeded or metrics export: context deadline exceeded.
• The Collector logs Exporting failed. Dropping data. with "error": "context deadline exceeded".
• Latency spikes on the exporting service as export goroutines block.
• Errors correlate with network egress, backend rate limits, or a downstream Collector under load.

Common Root Causes

• Timeout too short for the network path — the default 5s OTLP timeout is exceeded on a slow or cross-region link to the backend.
• Backend or Collector overloaded — the receiving endpoint is slow to ACK, so exports queue up and time out.
• Wrong or unreachable endpoint — DNS resolution or a firewall stalls the connection until the deadline fires.
• TLS handshake delays — misconfigured or slow TLS negotiation adds seconds to every export.
• Large batches — oversized batch processor payloads take longer than the timeout to transmit.
• No retry/queue headroom — sending_queue fills, so new exports wait and then exceed the deadline.

Diagnostic Workflow

Confirm the endpoint and timeout the SDK is using. For an application exporter, the environment variables are authoritative:

echo "$OTEL_EXPORTER_OTLP_ENDPOINT"       # e.g. http://otel-collector:4317
echo "$OTEL_EXPORTER_OTLP_TIMEOUT"        # milliseconds; default 10000
echo "$OTEL_EXPORTER_OTLP_PROTOCOL"       # grpc | http/protobuf

Increase the exporter timeout in the Collector and add explicit retry/queue settings:

exporters:
  otlp:
    endpoint: backend.example.com:4317
    timeout: 30s
    tls:
      insecure: false
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s
    sending_queue:
      enabled: true
      num_consumers: 10
      queue_size: 5000

processors:
  batch:
    timeout: 5s
    send_batch_size: 512
    send_batch_max_size: 512

service:
  telemetry:
    logs:
      level: info
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Read the Collector logs for the exporter that is timing out and confirm whether data is being retried or dropped:

journalctl -u otelcol-contrib --since '15 min ago' | grep -i 'deadline\|dropping data\|export'

Test raw connectivity and latency to the OTLP endpoint from the exporting host:

grpcurl -plaintext otel-collector:4317 list        # gRPC reachability
curl -v -m 5 http://otel-collector:4318/v1/traces   # http/protobuf reachability

Example Root Cause Analysis

A service in us-east-1 exported traces directly to a vendor OTLP endpoint in eu-west-1. Baseline round-trip latency was ~90ms, but during peak the vendor throttled and ACKs took 6–8 seconds — longer than the default 5s gRPC timeout. The SDK logged context deadline exceeded and dropped roughly 15% of spans.

The fix had two parts. First, OTEL_EXPORTER_OTLP_TIMEOUT was raised to 30000 (30s) so slow ACKs no longer tripped the deadline. Second, a regional Collector was deployed as a local gateway: the service exported to the in-region Collector over a sub-millisecond link, and the Collector’s otlp exporter buffered to the vendor with retry_on_failure and a sending_queue of 5000. Span loss dropped to zero because retries absorbed the transient throttling instead of the SDK dropping data.

Prevention Best Practices

• Run a local/gateway Collector so applications export over a fast local hop, not directly across regions.
• Set realistic timeout values (OTEL_EXPORTER_OTLP_TIMEOUT) that account for real backend latency, not just the LAN case.
• Always enable retry_on_failure and a bounded sending_queue on Collector exporters to absorb transient slowness.
• Keep batch payloads modest (send_batch_max_size) so a single export fits comfortably inside the timeout.
• Alert on the Collector’s otelcol_exporter_send_failed_spans metric to catch deadline errors before data loss grows.
• Verify TLS is terminated efficiently; avoid per-export handshakes by keeping connections alive.

Quick Command Reference

# Inspect SDK exporter configuration
env | grep OTEL_EXPORTER_OTLP

# Watch Collector for deadline/drop events
journalctl -u otelcol-contrib -f | grep -i 'deadline\|dropping'

# Test OTLP gRPC and HTTP endpoints
grpcurl -plaintext otel-collector:4317 list
curl -v -m 5 http://otel-collector:4318/v1/traces

# Scrape the Collector's own metrics for send failures
curl -s http://localhost:8888/metrics | grep otelcol_exporter_send_failed

Conclusion

context deadline exceeded means an OTLP export ran out of time before the backend acknowledged it. The durable fix is rarely a single knob: raise timeout to match real latency, front your applications with a local Collector, and lean on retry_on_failure plus a sending_queue so transient backend slowness is absorbed rather than turned into dropped telemetry. Instrument the Collector’s own metrics so deadline errors become an early warning instead of silent gaps in your traces.