OpenTelemetry Specification v1.62.0 - OTLP timeout and shutdown rules
OpenTelemetry Specification v1.62.0 was published on October 22, 2026. Its most useful clarification for operators is that the OTLP exporter timeout covers a whole batch export, including every request attempt and wait between retries.
The full release notes are on the GitHub release page.
OTLP timeouts cover the entire batch
The timeout clarification in PR #5347 puts all attempts and retry waits inside one export time budget. An earlier deadline from the caller takes precedence.
For anyone reviewing exporter behavior, the practical check is whether retries consume that same budget. A new attempt cannot start a fresh full timeout for the batch. Caller deadlines also need to remain effective when an export is waiting to retry.
Metric readers flush during shutdown
A periodic exporting MetricReader must include the effects of ForceFlush when it runs Shutdown, as specified in PR #5305. This makes flushing part of the reader’s required shutdown behavior. It gives SDK maintainers a concrete requirement to check when testing application termination.
Tracing also gains a Sampler.Shutdown operation in PR #5335. That adds an explicit lifecycle operation for samplers. If you maintain a custom sampler, this is the API addition to review as your SDK adopts the specification.
Unknown resource detectors degrade gracefully
Declarative configuration should degrade gracefully when it encounters an unrecognized resource detector. PR #5323 keeps errors for other missing SDK plugin components.
The distinction matters when reviewing configuration failures. Resource detector names now have a specific tolerance rule, while other plugin references still require the expected component. For shared configuration, check which kind of component is missing before treating the configuration as acceptable. This change does not extend graceful handling to every unknown plugin.
Security fixes can change stable behavior
PR #5357 allows narrowly scoped security changes to stable SDK and Contrib behavior without a major version bump. The allowance covers configuration defaults, supported values, and emitted telemetry, while requiring API compatibility.
Release notes for those changes must explain the security rationale, user impact, and migration. For operators, the implication is concrete: a compatible API can accompany a change in defaults or telemetry. Read the stated impact when evaluating a security update, even if the major version stays the same.
Where to get it
This is a specification release. Check your SDK’s release notes for implementation support.