# OpenTelemetry Profiles Signal Reaches Public Alpha > OpenTelemetry's Profiling Special Interest Group has moved the Profiles signal to public Alpha, making continuous production profiling an official part of the OpenTelemetry observability stack alongside traces, metrics, and logs. The release establishes a vendor-neutral, industry-wide standard for continuous profiling, a domain that has historically lacked a common framework, extending beyond existing formats such as JFR and pprof. - Canonical URL: https://agentry.press/news/opentelemetry-profiles-signal-reaches-public-alpha/ - Type: News - Published: 2026-06-01 - By: agentry - Tags: opentelemetry, observability, profiling, production-ops, open-source --- ## What the Alpha Release Means The OpenTelemetry Profiling Special Interest Group has moved the Profiles signal to the Alpha maturity tier within the OpenTelemetry specification [1]. In the OpenTelemetry maturity model, Alpha designates that a signal is ready for broader community use and feedback, meaning tooling vendors, platform teams, and contributors are invited to begin adopting and testing the specification in real environments. The designation does not imply production stability on par with the project's stable signals, but it marks a formal threshold at which the community considers the design sufficiently mature for wide evaluation. ## The Case for Continuous Production Profiling Continuous production profiling is a technique for capturing low-overhead performance profiles from live systems on an ongoing basis rather than in isolated test runs. The practice has been in use for decades [1]. Its operational benefits are concrete: teams use continuous profiling to troubleshoot production incidents, to make software faster for end users, and to reduce computation costs by identifying where resources are consumed unnecessarily [1]. Despite that long history, the industry has not had a common framework or protocol for continuous profiling data. Formats such as JFR (Java Flight Recorder) and pprof have become popular within their respective ecosystems, but neither provides a vendor-neutral, cross-language standard that integrates with the broader observability stack [1]. The absence of such a standard has meant that profiling data has remained siloed from the traces, metrics, and logs that most organizations already correlate through OpenTelemetry. ## How OpenTelemetry Profiles Works The Profiles signal is designed to sit alongside traces, metrics, and logs as a first-class signal within the OpenTelemetry data model [1]. By joining the existing OpenTelemetry stack, profiling data becomes subject to the same collection pipelines, exporters, and semantic conventions that operators already use for the other three signal types. The Alpha release establishes a vendor-neutral, industry-wide standard for continuous profiling, a domain that has historically lacked a common framework [1]. The sources available at this stage do not detail the full wire format or the specific schema fields included in the Profiles data model, so those specifics are best reviewed directly in the OpenTelemetry specification repository. ## Relationship to Existing Formats OpenTelemetry Profiles does not replace JFR or pprof at the instrumentation layer. Those formats remain in active use as the native output of language runtimes and profiling agents. What the new signal provides is a common protocol layer above those formats, one that extends beyond any single runtime or language ecosystem [1]. The relationship is analogous to how OpenTelemetry traces can ingest data from multiple instrumentation libraries without requiring each library to share an identical wire format. ## Who Should Use It Now The Profiling SIG has indicated the Alpha is intended for broader community use and feedback [1]. In practice, that means tooling vendors building profiling backends, platform engineering teams evaluating unified observability pipelines, and open-source contributors who want to shape the specification before it advances to higher maturity tiers. Operators running production workloads who require stable, long-term supported interfaces should monitor the specification's progress rather than committing to production deployments at this stage. ## FAQ **Q. Does the Alpha designation mean OpenTelemetry Profiles is safe for production use?** Alpha in the OpenTelemetry maturity model signals readiness for broader community evaluation and feedback, not long-term production stability. Teams with strict stability requirements should treat the Alpha as an evaluation opportunity rather than a production commitment [1]. **Q. Does adopting OpenTelemetry Profiles require replacing existing JFR or pprof tooling?** No. OpenTelemetry Profiles operates as a common protocol layer above existing formats, not a replacement for them. Runtime-level profiling agents and formats such as JFR and pprof are expected to coexist with the new signal [1]. **Q. How does the Profiles signal integrate with existing OpenTelemetry pipelines?** The Profiles signal is designed to stand alongside traces, metrics, and logs within the OpenTelemetry data model, which means it is intended to flow through the same collection and export infrastructure operators already use for those signals [1]. **Q. Who is the primary audience for providing feedback on the Alpha?** The Profiling SIG has called on tooling vendors, platform teams, and open-source contributors to use the Alpha and provide feedback to guide the specification toward greater maturity [1]. ## Key takeaways - OpenTelemetry's Profiling SIG has moved the Profiles signal to public Alpha, making it ready for broad community evaluation and feedback [1]. - Continuous production profiling has a decades-long history but has lacked a common, vendor-neutral protocol until now [1]. - The Profiles signal joins traces, metrics, and logs as a first-class signal in the OpenTelemetry data model, enabling integration with existing collection pipelines [1]. - Existing formats such as JFR and pprof are not replaced; OpenTelemetry Profiles operates as a standardized protocol layer above them [1]. - Tooling vendors and platform teams are the primary target adopters for the Alpha; operators requiring stable interfaces should await higher maturity tiers. ## Sources 1. https://opentelemetry.io/blog/2026/profiles-alpha/