# OpenTelemetry Profiles reaches public alpha > OpenTelemetry’s profiling signal entered public alpha, giving implementers a shared data model and OTLP path while keeping stability expectations explicit. Canonical URL: https://www.devobs.io/news/news-opentelemetry-profiles-public-alpha/ By: Arjun Shah Published: 2026-09-06T11:58:54.649Z Updated: 2026-09-06T11:58:54.649Z Event date: 2026-03-26 Section: Infrastructure OpenTelemetry moved its Profiles signal into public alpha on March 26, making continuous profiling a first-class part of the project’s observability model. The [project announcement](https://opentelemetry.io/blog/2026/profiles-alpha/) says the milestone covers the data model, protocol support, and an initial implementation path, while also warning that alpha still permits breaking changes. ## Profiles can now travel with other telemetry A profile answers a different question from a trace or metric: which functions consumed CPU or memory during a period. Standardizing that signal matters because teams have often used vendor-specific agents, formats, and backends. OpenTelemetry’s approach gives collectors and backends a common envelope for profiles alongside traces, metrics, and logs. The practical gain is correlation. During a latency regression, an operator can move from a slow span to the code paths active during the same interval instead of reproducing the workload under a separate profiler. That reduces the gap between identifying an affected service and locating the expensive function. ## Alpha is an integration checkpoint The alpha label is a boundary, not a promise of wire stability. Collector builders and profiling vendors can now test interoperability and expose missing semantics, but production teams should pin component versions and expect migrations. A sensible trial is one service with measurable CPU cost: send profiles through the same collector path as traces, verify resource attributes survive, and test whether the backend links the signals reliably. The failure case is treating the milestone as universal compatibility. A receiver accepting OTLP profiles does not guarantee identical aggregation, symbolization, or query behavior across backends. Teams should document the exact producer, collector, and storage versions used in a pilot. The release makes coordinated experimentation possible; it does not remove the need to validate the complete profiling pipeline. ## Source references -