🚨 Telegraf Error Guide: '[outputs.influxdb_v2] 429 Too Many Requests' — Fix InfluxDB Cloud Rate Limits

Overview

The influxdb_v2 output writes line protocol to InfluxDB Cloud or OSS 2.x over HTTP. When you exceed the org’s write-rate or series/cardinality entitlement, the server rejects the batch with HTTP 429 and Telegraf logs it verbatim:

2026-07-12T12:00:00Z E! [outputs.influxdb_v2] When writing to [https://us-east-1-1.aws.cloud2.influxdata.com]: 429 Too Many Requests

InfluxDB Cloud commonly attaches a Retry-After and rate-limit headers, which Telegraf honors before retrying the same batch:

2026-07-12T12:00:05Z W! [outputs.influxdb_v2] Failed to write metric to bucket (will be dropped: 429 Too Many Requests): Retry-After: 30

Metrics accumulate in the output buffer while writes are throttled; if the buffer fills, the oldest metrics are dropped.

Symptoms

• Writes to InfluxDB Cloud fail in bursts with 429 Too Many Requests while smaller deployments succeed.
• journalctl -u telegraf shows repeated 429s clustered on high-volume flushes, then recovery.
• The InfluxDB Cloud UI Usage page shows write requests or cardinality near the plan ceiling.
• internal_write metrics show rising buffer_size and non-zero metrics_dropped.
• The error worsens after adding hosts or high-cardinality tags (per-request IDs, container IDs, timestamps-as-tags).

Common Root Causes

• Plan write-rate limit exceeded — InfluxDB Cloud caps write requests/MB per five-minute window per org; bursty flushes from many agents cross it.
• Series cardinality limit — the org’s total series count hit the plan ceiling; new series are rejected with 429 until cardinality drops.
• Flushes too frequent or unjittered — every agent flushes on the same flush_interval, creating a synchronized spike that trips the per-org limiter.
• Uncompressed payloads — without content_encoding = "gzip", batches are larger and count more against MB-based limits.
• Batches too large or too small — oversized metric_batch_size sends huge requests; tiny batches send too many requests per window.
• Runaway cardinality from tags — high-cardinality tag values (UUIDs, timestamps, full URLs) explode series count and hit the cardinality cap.
• Multiple agents sharing one token/org — combined throughput from a fleet exceeds what any single agent’s config suggests.

Diagnostic Workflow

First confirm it is genuinely rate limiting and read the server’s guidance from the response headers. A raw write reproduces the 429 and exposes Retry-After / X-Rate-Limit-*:

curl -i -XPOST "https://us-east-1-1.aws.cloud2.influxdata.com/api/v2/write?org=${INFLUX_ORG}&bucket=${INFLUX_BUCKET}&precision=ns" \
  -H "Authorization: Token ${INFLUX_TOKEN}" \
  -H "Content-Type: text/plain; charset=utf-8" \
  --data-binary 'test,host=demo value=1'
# Look for: HTTP/1.1 429, Retry-After, X-Rate-Limit-Limit, X-Rate-Limit-Remaining, X-Rate-Limit-Reset

Run only the output path with debug to see batch sizes and retry timing:

telegraf --config /etc/telegraf/telegraf.conf --test-wait 30 --debug 2>&1 | grep -i influxdb_v2

Tune the agent to spread and shrink write pressure — jitter flushes, cap batch size, and enable gzip:

[agent]
  flush_interval = "30s"
  flush_jitter = "10s"       # de-synchronize a fleet so they don't all POST at once
  metric_batch_size = 5000
  metric_buffer_limit = 100000

[[outputs.influxdb_v2]]
  urls = ["https://us-east-1-1.aws.cloud2.influxdata.com"]
  token = "${INFLUX_TOKEN}"
  organization = "${INFLUX_ORG}"
  bucket = "${INFLUX_BUCKET}"
  content_encoding = "gzip"  # smaller payloads count less against MB limits
  timeout = "15s"

Cut cardinality at the source with an aggregator and by dropping high-cardinality tags before they ever reach InfluxDB:

# Roll raw points into 60s means to reduce write rate and series churn
[[aggregators.basicstats]]
  period = "60s"
  drop_original = true
  stats = ["mean", "max", "min"]

# Strip a tag that explodes cardinality
[[processors.regex]]
  namepass = ["*"]
  [[processors.regex.tags]]
    key = "request_id"
    pattern = ".*"
    replacement = ""

Then check your org’s live cardinality and usage in the InfluxDB Cloud UI (Usage) or with the CLI, and delete or downsample offending measurements.

Example Root Cause Analysis

A platform team onboarded 400 new nodes to an InfluxDB Cloud starter org over a weekend. Monday morning dashboards went patchy and Telegraf logs on many hosts showed [outputs.influxdb_v2] ... 429 Too Many Requests with Retry-After: 60. Every agent used the default flush_interval = "10s" with no flush_jitter, so all 400 hosts POSTed in the same one-second window, spiking write requests far past the plan’s per-five-minute ceiling even though average throughput was modest.

They set flush_interval = "30s", flush_jitter = "15s", enabled content_encoding = "gzip", and added a 60s basicstats aggregator on the noisiest measurement. The synchronized spike flattened, per-window request counts dropped below the limit, and the 429s stopped. The lesson: InfluxDB Cloud rate limits are enforced per-org over a rolling window, so a synchronized fleet trips them long before raw data volume looks large — jitter and aggregate before you upgrade the plan.

Prevention Best Practices

• Always set flush_jitter on fleets so agents do not flush in lockstep and create synchronized bursts.
• Enable content_encoding = "gzip" to shrink payloads against MB-based write limits.
• Control cardinality aggressively: never use UUIDs, timestamps, or full URLs as tags; use processors.regex/tagexclude to drop them.
• Aggregate or downsample with aggregators.basicstats when raw resolution is not needed at the write path.
• Watch internal_write (buffer_size, metrics_dropped) and the InfluxDB Cloud Usage page to catch limits before data drops.
• Size the org/plan for real cardinality and write rate; when 429s persist after tuning, upgrade the plan rather than dropping metrics.

Quick Command Reference

# Reproduce the 429 and read rate-limit headers
curl -i -XPOST "https://<host>/api/v2/write?org=${INFLUX_ORG}&bucket=${INFLUX_BUCKET}" \
  -H "Authorization: Token ${INFLUX_TOKEN}" --data-binary 'test,host=demo value=1'

# Watch influxdb_v2 output behavior with debug
telegraf --config /etc/telegraf/telegraf.conf --test-wait 30 --debug 2>&1 | grep -i influxdb_v2

# Tail live 429 / retry activity
journalctl -u telegraf -f | grep -iE '429|retry-after|influxdb_v2'

Related Guides

• Telegraf outputs.http 429 Too Many Requests
• Telegraf metric buffer overflow
• Telegraf write 413 Request Entity Too Large

More fixes in the Telegraf guides.

Conclusion

[outputs.influxdb_v2] ... 429 Too Many Requests means InfluxDB Cloud or OSS is rate limiting your org — you have crossed a write-rate window or a series/cardinality entitlement, not hit a generic HTTP fault. Read the Retry-After and X-Rate-Limit-* headers, then spread load with flush_jitter, shrink it with content_encoding = "gzip", and cut series churn with aggregation and tag hygiene. When 429s persist after tuning cardinality and flush timing, the plan itself is the ceiling to raise.