[BUG] OTLP metric export silently stops when OTEL_RESOURCE_ATTRIBUTES has >12 entries (regression in 2.1.161)

Open 💬 0 comments Opened Jun 25, 2026 by RocketRaccoon

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

[BUG] OTLP metric export silently stops when OTEL_RESOURCE_ATTRIBUTES has >12 entries (regression in 2.1.161)

What happened

Setting CLAUDE_CODE_ENABLE_TELEMETRY=1 with OTEL_METRICS_EXPORTER=otlp and an
OTEL_RESOURCE_ATTRIBUTES value containing more than ~12 entries causes Claude Code to export
zero metrics over OTLP. The HTTP export returns 200 (or there is simply no export attempt) — no
error on stderr, nothing in --debug-file. Logs and traces from the same process continue to export
normally
, carrying all the same resource attributes. Reducing OTEL_RESOURCE_ATTRIBUTES to ≤12
entries makes metric export work again.

This started in 2.1.161 and is still present in 2.1.191 (latest at time of writing). The 2.1.161
changelog entry that lines up:

OTEL_RESOURCE_ATTRIBUTES values are now included as labels on metric datapoints, so you can slice usage metrics by custom dimensions like team or repo

It looks like the new "copy every resource attribute onto each metric datapoint" path trips an
attribute-count limit (or throws and is swallowed) once the datapoint's attribute set gets large,
killing the whole metric export. Logs/traces don't go through that path, which is why only metrics break.

What Should Happen?

Expected vs actual

  • Expected: metric export is unaffected by the number of resource attributes (or, at worst, drops

the extra datapoint labels while still exporting the metric).

  • Actual: the entire OTLP metric pipeline goes silent above ~12 resource attributes, with no error.

Error Messages/Logs

No errors logs available

Steps to Reproduce

Reproduction

Point at any OTLP metrics backend (or a local otel-collector with debug exporter).

Works (≤12 resource attributes) — metrics export:

CLAUDE_CODE_ENABLE_TELEMETRY=1 \
OTEL_METRICS_EXPORTER=otlp OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
OTEL_EXPORTER_OTLP_ENDPOINT=https://<your-collector> \
OTEL_METRIC_EXPORT_INTERVAL=2000 \
OTEL_RESOURCE_ATTRIBUTES="a1=v,a2=v,a3=v,a4=v,a5=v,a6=v,a7=v,a8=v,a9=v,a10=v,a11=v,a12=v" \
claude --print "write a few paragraphs so the session lasts a few seconds"
# -> claude_code.session.count / cost.usage / token.usage all arrive

Broken (13 resource attributes) — metrics silently absent, logs/traces still arrive:

... OTEL_RESOURCE_ATTRIBUTES="a1=v,...,a13=v" ...
claude --print "..."
# -> no claude_code.* metrics; logs + traces still export with all 13 attrs

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.160

Claude Code Version

2.1.191

Platform

AWS Bedrock

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Threshold (measured)

≤12 OTEL_RESOURCE_ATTRIBUTES entries export; ≥13 do not. It is attribute count, not byte size
(13 short attrs break; 12 long-valued attrs are fine).

Workaround

OTEL_METRICS_INCLUDE_RESOURCE_ATTRIBUTES=false restores metric export (resource attrs then ride the
OTLP resource block only). Confirmed: with the flag set and 21 resource attributes,
token.usage/cost.usage/session.count all export reliably on 2.1.191.

Suggested fix

In the path added by 2.1.161, either (a) cap/skip the per-datapoint resource-attribute copy without
aborting the export, or (b) raise/configure the limit and surface a warning instead of silently
dropping all metrics. A swallowed exception around the datapoint-attribute assignment is the most
likely culprit.

Impact

Anyone who sets a rich OTEL_RESOURCE_ATTRIBUTES (CI bots, multi-team setups with cicd./vcs./cost
attribution) loses all usage/cost metrics silently while logs/traces keep flowing — easy to not
notice for a long time.

View original on GitHub ↗