{"version":"2.1.281","anchor":"new-otlp-export-health-telemetry-for-customer-opentelemetr","canonical_anchor":"new-otlp-export-health-telemetry-for-customer-opentelemetr","heading":"New otlp_export health telemetry for customer OpenTelemetry exporters","tier":null,"area":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/new-otlp-export-health-telemetry-for-customer-opentelemetr","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### New `otlp_export` health telemetry for customer OpenTelemetry exporters\n\nClaude Code now records whether its OpenTelemetry exports to your own collector succeed or fail, with an error code on failure\n\n**What**\n\nOpenTelemetry (OTLP) is a standard way to send metrics, logs and traces to a monitoring system you run yourself. When you set this up, Claude Code now records an `otlp_export` event about how those exports went:\n\n- The first successful export of each kind (metrics, logs or traces) records one success event.\n\n- Each distinct failure records one failure event with an error code. Codes include `grpc_N`, `http_401`, `http_403`, `http_Nxx`, \"timeout\", \"http_retries_exhausted\", `headers_helper_*`, SSL codes or \"other\".\n\n- Failure events also record the protocol, the HTTP status and whether a proxy was used.\n\nConsole and Prometheus exporters are not tracked. Traces are also not tracked when the traces endpoint matches an internal check. The debug line printed on the first export is unchanged.\n\n**Why**\n\nProblems with your telemetry setup now leave a record with a specific reason, such as a rejected login or a timeout."}