🚨 OpenTelemetry Error Guide: 'no more retries left; dropping data' — Stop Telemetry Loss

Overview

This error is logged by the OpenTelemetry Collector’s exporter helper when repeated export attempts fail and the retry budget is exhausted. The Collector gives up and discards the batch:

2026-07-09T09:41:03.552Z	error	exporterhelper/queue_sender.go:174	Exporting failed. No more retries left. Dropping data.	{"kind": "exporter", "data_type": "traces", "name": "otlp", "error": "max elapsed time expired context deadline exceeded", "dropped_items": 2048}

No more retries left. Dropping data. means retry_on_failure reached its max_elapsed_time (or was disabled) while the backend kept rejecting or timing out exports. Unlike a transient retry, this line is terminal: those spans, metrics, or logs are gone.

Symptoms

• Gaps in traces/metrics that correlate with backend outages or throttling windows.
• Collector logs repeat Exporting failed then a final No more retries left. Dropping data.
• The otelcol_exporter_send_failed_spans / _metric_points counters climb.
• sending_queue fills, then the Collector sheds load.
• The underlying error field names a cause: deadline exceeded, connection refused, 429, or ResourceExhausted.

Common Root Causes

• Backend down or throttling — the destination is unavailable or returning 429/ResourceExhausted for longer than max_elapsed_time.
• Retry budget too small — max_elapsed_time is shorter than the typical outage, so retries expire before the backend recovers.
• Queue saturation — sending_queue is full and the exporter cannot buffer the backlog.
• Persistent misconfiguration — a bad endpoint or expired credential makes every retry fail identically.
• Insufficient consumers — too few num_consumers to drain the queue at the incoming rate.
• No persistent queue — an in-memory queue is lost on restart, compounding loss during long outages.

Diagnostic Workflow

Inspect the retry and queue settings on the failing exporter and give the retry budget room to ride out realistic outages:

exporters:
  otlp:
    endpoint: backend.example.com:4317
    timeout: 30s
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 900s        # ride out a 15-minute backend blip
    sending_queue:
      enabled: true
      num_consumers: 20
      queue_size: 10000
      storage: file_storage          # persist across restarts

extensions:
  file_storage:
    directory: /var/lib/otelcol/queue

service:
  extensions: [file_storage]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Identify the terminal error and how much data was dropped:

journalctl -u otelcol-contrib --since '30 min ago' | grep -i 'no more retries\|dropping data'

Watch the Collector’s own metrics for queue pressure and send failures:

curl -s http://localhost:8888/metrics | grep -E 'otelcol_exporter_send_failed|otelcol_exporter_queue_size|otelcol_exporter_queue_capacity'

Confirm the backend is actually reachable and healthy from the Collector host:

grpcurl -plaintext backend.example.com:4317 list

Example Root Cause Analysis

During a backend maintenance window, a vendor OTLP endpoint returned ResourceExhausted for ~12 minutes. The Collector’s retry_on_failure used the default max_elapsed_time: 300s (5 minutes) and an in-memory sending_queue. Retries expired after 5 minutes, and the Collector logged No more retries left. Dropping data. for the remaining 7 minutes of the outage — losing roughly 4 million spans.

Two changes closed the gap. First, max_elapsed_time was raised to 900s so retries survived a typical maintenance window. Second, the sending_queue was backed by the file_storage extension (storage: file_storage) so buffered batches persisted on disk and across Collector restarts, and queue_size was raised to absorb 15 minutes of throughput. In the next maintenance window the backend recovered and the persisted queue drained with zero drops.

Prevention Best Practices

• Size max_elapsed_time to exceed your longest realistic backend outage, not the default 5 minutes.
• Back sending_queue with the file_storage extension so buffered data survives restarts and long outages.
• Right-size queue_size and num_consumers to your peak throughput so the queue does not overflow.
• Alert on otelcol_exporter_send_failed_* and otelcol_exporter_queue_size approaching queue_capacity.
• Fix persistent errors fast: a 429 loop or bad credential will burn the entire retry budget uselessly.
• Consider a second exporter/backend for critical pipelines so one outage does not force data loss.

Quick Command Reference

# Find terminal drop events
journalctl -u otelcol-contrib | grep -i 'no more retries'

# Queue and failure metrics
curl -s http://localhost:8888/metrics | grep -E 'queue_size|queue_capacity|send_failed'

# Verify backend reachability
grpcurl -plaintext backend.example.com:4317 list

# Confirm persistent queue directory exists and is writable
ls -ld /var/lib/otelcol/queue

Conclusion

No more retries left. Dropping data. is the Collector telling you it fought a failing backend until its retry budget ran out. The remedy is resilience, not just a bigger timeout: extend max_elapsed_time to cover real outages, persist the sending_queue with file_storage so a restart does not compound the loss, and alert on queue and send-failure metrics. With those in place, a transient backend blip becomes buffered-and-recovered instead of permanently dropped telemetry.