In case you missed it: OpenTelemetry (OTel) has officially achieved CNCF graduated status! It now stands proudly alongside amazing open source projects such as Kubernetes and Prometheus, to name just a few. It’s been a long journey, and we’re very excited… But, now what? To understand where we’re going, it’s important to understand where we came from.
History
In the not-so-distant past, telemetry signals were not standardized. This meant telemetry formats differed from tool to tool, with each telemetry vendor creating and maintaining its own instrumentation libraries. Vendor lock-in was a huge problem: If you wanted to switch vendors, you had to strip out the previous vendor’s libraries from your code and replace them with the new vendor’s libraries. As a result, switching vendors was a nontrivial task.
In addition, the three core telemetry signals – traces, logs, and metrics – were treated as separate, so there was no easy way to correlate them. Because of this, the observability story was incomplete.
Previous attempts had been made at standardization: the CNCF’s OpenTracing, and Google’s OpenCensus, forming the basis for what was to become OpenTelemetry.
In the interest of having a single standard, OpenCensus and OpenTracing were merged to form OpenTelemetry in May 2019. OpenTelemetry takes the best of both worlds, and then some, providing a tracing, metrics, and logs specification, a set of standardized APIs, and language specific implementations of these APIs, in addition to the Collector.
Both OpenCensus and OpenTracing are now officially archived. OpenTracing was archived in January 2022, and OpenCensus was archived in July 2023.
With the backing of all major observability vendors, and an active developer and end user community, OpenTelemetry became the de facto open standard for telemetry.
Growth
OpenTelemetry is the second-highest velocity project in the CNCF, just behind Kubernetes. According to the CNCF, OpenTelemetry has “over 12,000 contributions, from over 2,800 companies and hundreds of maintainers across various language-specific Special Interest Groups (SIGs).”
Since its inception, traces, logs, and metrics have reached general availability (GA). Profiling was added as a new OTel signal. The OpenTelemetry Demo has expanded. The OTel Collector has expanded, with new components being added regularly. We’ve seen the addition of new components to the OTel ecosystem to help make it more ergonomic, including OpAMP, the OTel Operator, OTel Weaver, and OTel Arrow.
This is a very impressive achievement, considering that OpenTelemetry is a mere seven years old. It sends a clear signal: OpenTelemetry is here to stay. And graduation helps to cement that.
Graduation!
OpenTelemetry achieved graduated status in May 2026, having started its path to graduation in 2025.
So what does it take to become a graduated CNCF project? Projects must fulfill the following criteria:
- Production adoption. Many different organizations, such as GitHub and Farfetch, run OpenTelemetry in production.
- Robust governance. OTel has a documented governance model with clearly defined roles around election and retirement, along with transparent communication and decision-making.
- Community health. OpenTelemetry has an established process for PR review and management. The project has a number of regular contributors across multiple organizations. Reviewers are responsive, ensuring that issues and fixes are addressed in a timely manner.
- Security. OTel has undergone at least one independent security audit, and all critical issues identified have been remediated.
- API stability. APIs are stable, properly versioned, and released at a regular cadence, with backwards compatibility ensured so as to not break existing implementations.
- Documentation. OTel’s documentation provides an architectural overview, along with user, operator, and contribution guides.
- TOC application and review. A graduation application template was submitted for review by the CNCF’s Technical Oversight Committee (TOC). You can check out OTel’s submission.
As you can see, a lot of work was done behind the scenes by many dedicated folks, ranging from OTel maintainers, to end users, to CNCF TOC members to make this happen.
We’d like to give a huge shoutout to all in the OpenTelemetry community who made graduation happen, and especially to Austin Parker, OpenTelemetry Governance Committee member and former Community Manager, who led the graduation effort with the CNCF.
What this means for you
So what does OpenTelemetry graduation mean for you, dear reader?
Dan Gomez Blanco, one of the maintainers of the OTel End User SIG put it perfectly in a recent LinkedIn post:
For end users, this graduation signals that OTel is far from being an “emerging standard”. Its contributor health, security and quality standards, governance processes, and wide adoption have been evaluated to be at the level required by any enterprise, of any scale. So, if you’re in the 25% of skeptics not using OTel, there’s really no excuse anymore. There has never been a better time to adopt it!
In a nutshell: OpenTelemetry is production-ready, and fully open for business. If your organization was holding out on using OpenTelemetry, you have no more excuses!
What’s next?
Software is never really “done”, and the same goes for OpenTelemetry. It will continue to grow and evolve: from the specification to the API & SDK to the Collector, and beyond.
Looking ahead, we see a strong need for observability around new types of workloads, such as agentic workflows, an area covered by the emerging generative AI semantic conventions. We’re also tackling challenges in areas that we hadn’t focused on as much previously, such as browser and mobile observability.
More mature teams are looking for guidance on using OpenTelemetry at scale. That’s where tools like Weaver, which helps teams define and govern their telemetry schemas, come into play. We’re also making OTel easier to roll out by packaging components into installable modules through OpenTelemetry Packaging, and by enabling zero-code instrumentation with the OpenTelemetry Injector.
OpenTelemetry has a long future ahead of it, but we also know that it’s only possible through continued work by maintainers and contributors, and of course, through continued support and adoption by our end users.
We can’t wait for what the future has in store for us, and we’re excited to have you along for the ride.
Facts Only
* OpenTelemetry achieved CNCF graduated status in May 2026.
* OpenTelemetry was formed in May 2019 through the merger of OpenCensus and OpenTracing.
* OpenTracing was archived in January 2022.
* OpenCensus was archived in July 2023.
* CNCF graduation criteria include production adoption, robust governance, community health, security audits, API stability, and documentation.
* GitHub and Farfetch use OpenTelemetry in production.
* The project has over 12,000 contributions from over 2,800 companies.
* Core telemetry signals include traces, logs, and metrics; profiling was added later.
* Ecosystem components include the OTel Collector, OpAMP, OTel Operator, OTel Weaver, and OTel Arrow.
* Austin Parker led the graduation effort with the CNCF.
Executive Summary
OpenTelemetry (OTel) has transitioned to graduated status within the Cloud Native Computing Foundation (CNCF), placing it in the same maturity tier as Kubernetes and Prometheus. This milestone follows a trajectory that began with the 2019 merger of OpenCensus and OpenTracing, aimed at eliminating vendor lock-in by standardizing telemetry signals—traces, logs, and metrics. To achieve graduation, the project demonstrated production adoption by organizations like GitHub and Farfetch, established robust governance, ensured API stability, and passed an independent security audit.
The project is currently characterized by high development velocity, with the recent addition of profiling as a signal and the expansion of the OTel Collector. Current initiatives focus on extending observability to agentic AI workflows, browser-based environments, and mobile platforms. For enterprises, this graduation signals that the project's security and quality standards are sufficient for large-scale production use, moving OTel from an emerging standard to a production-ready framework.
Full Take
The strongest version of this narrative is that the industry has successfully solved the "vendor lock-in" problem in observability by creating a neutral, community-governed standard that prioritizes interoperability over proprietary ecosystems. By unifying fragmented signals (traces, logs, metrics) into a single specification, OpenTelemetry lowers the cost of switching providers and increases the reliability of system monitoring.
However, the framing employs a subtle "appeal to popularity" and a "false binary" to drive adoption. By positioning the choice as "production-ready standard vs. unfounded skepticism," it suggests that any remaining hesitation is a lack of evidence rather than a potentially valid architectural preference. The narrative implies that "graduation" is the final seal of approval, effectively using the CNCF's institutional prestige to shut down further debate regarding the project's utility.
Patterns detected: ARC-0061 Appeal to Popularity, ARC-0021 False Binary
The driving paradigm is the "Standardization Era" of cloud computing, where the value shift moves from the tool itself to the data format. The unstated assumption is that a single, universal standard is inherently superior to a diverse ecosystem of specialized, competing tools. While this benefits the enterprise by reducing risk, it may consolidate power among the "major observability vendors" who back the standard, potentially creating a new form of collective lock-in.
If this were a coordinated influence campaign, the playbook would involve using institutional milestones (graduation) and social proof (celebrity companies) to create a "fear of missing out" (FOMO) among CTOs, framing non-adoption as technical obsolescence. The actual content matches this pattern moderately, specifically in the "no more excuses" rhetoric.
Bridge Questions:
1. Does the standardization of telemetry signals stifle innovation by creating a "lowest common denominator" for what can be measured?
2. How does the influence of "major observability vendors" on the governance committee affect the neutrality of the specification?
3. What are the hidden costs of migrating to a "standard" that continues to evolve its API and SDKs?
Counterstrike Scan: The content aligns with a standard vendor-adjacent promotional playbook, using institutional validation to convert skeptics.
Sentinel — Human
This text reads like an enthusiastic, well-informed piece written by a community member or advocate celebrating a significant open-source milestone, blending technical history with motivational calls to action.