On May 11, 2026, OpenTelemetry reached Graduated status at the Cloud Native Computing Foundation (CNCF), the highest maturity level a CNCF project can hold. The move was made public ten days later, on May 21, at the Observability North America Summit. Only a small number of projects ever reach this level, and Kubernetes is the most well known example. OpenTelemetry is now the second one most people will recognize.
If you already run OpenTelemetry, whether that is through the Collector, an SDK in your own application code, or the Elastic Distribution of OpenTelemetry (EDOT) I have covered before on this site, graduation itself does not change anything about how your pipelines work today. What it does confirm, with CNCF’s own technical review behind it, is that OpenTelemetry is no longer the safe-but-unproven choice. It is the default one. Here is what actually backs that up, and where the project is still genuinely unsettled.
What “Graduated” Actually Means at CNCF
CNCF projects move through three stages: Sandbox, Incubating, and Graduated. Each step up requires a formal application reviewed by CNCF’s Technical Oversight Committee (TOC), the group responsible for the foundation’s technical governance. Graduation is not a popularity vote. It requires proof of things like a documented and diverse set of committers from more than one organization, a clear governance and security process, and evidence that the project is genuinely used in production at scale by companies outside the ones who built it.
OpenTelemetry’s application was sponsored by TOC members Emily Fox and Davanum Srinivas, who ran the technical due diligence. OpenTelemetry was donated to CNCF back in 2019, formed from the merger of two earlier projects, OpenTracing and OpenCensus. It took a little over seven years from that donation to reach Graduated status.
The Numbers Behind the Milestone
According to CNCF’s own graduation announcement, OpenTelemetry has received contributions from more than 12,000 people across more than 2,800 companies, and it holds the second-highest development velocity of any project in the CNCF landscape, behind only Kubernetes itself. That landscape now includes more than 240 projects, which gives some sense of scale.
The project’s scope has also grown well past where it started. OpenTelemetry now covers four separate telemetry signals.
- Traces, showing how a single request moves across services
- Metrics, numeric measurements collected over time
- Logs, timestamped records of discrete events
- Profiles, the newest addition, showing exactly where CPU and memory time is being spent inside your code
- Procurement conversations get easier. If you have ever had to justify picking an open-source instrumentation layer over a vendor’s proprietary agent to a security or platform review board, “CNCF Graduated, same tier as Kubernetes” is a materially stronger answer than “actively maintained open-source project.”
- Cloud provider support keeps deepening. Azure Monitor now documents direct OTLP (OpenTelemetry’s own data format) ingestion. AWS has added OpenTelemetry metrics support for CloudWatch and Amazon EKS Container Insights. Google Cloud documents OTLP support for Cloud Trace and Cloud Monitoring. None of this required graduation to happen, but graduation is a strong signal that this investment from the major clouds will keep growing rather than being walked back.
- The Collector config you already wrote keeps working. Graduation does not introduce breaking changes to existing pipelines. If your current setup follows a config close to what I walked through in my OpenTelemetry Collector configuration guide, nothing about that structure needs to change because of this announcement.
- Profiling is still newer than the other three signals and does not yet have the same depth of backend support or tooling maturity that traces, metrics, and logs have built up over the years.
- The GenAI and MCP semantic conventions are explicitly marked as under active development, not stable, inside the specification itself. Field names and span structures there can still change in future releases. I go into this in more detail, including exactly which fields are involved, in the MCP tracing article linked above.
Traces, metrics, and logs have all reached general availability. Profiling is newer and still maturing, but it is the clearest sign of where the project is heading, toward being the one instrumentation layer that feeds every kind of telemetry data into whatever backend you choose, instead of needing a separate agent for each signal type.
Why CNCF Is Talking About AI Agents in a Graduation Announcement
Chris Aniszczyk, CNCF’s CTO, said graduation “provides yet another indication that OTel has become a de facto standard for collecting telemetry data” and specifically called out that the project will “play a major role in instrumenting artificial intelligence agents.” That is not a throwaway line. It reflects a real, current push inside OpenTelemetry: generative AI semantic conventions, a shared set of naming rules for recording what a model call or an agent’s tool call actually did.
I wrote about the newest part of that work directly on this site. OpenTelemetry now traces MCP tool calls, meaning the moment an agent calls an outside tool through the Model Context Protocol can show up in the same trace as the model call that triggered it. Mitch Ashley of Futurum Group made the same connection when discussing the graduation: agentic AI applications are about to generate orders of magnitude more telemetry signal than traditional applications ever did, and having a single, vendor neutral standard already in place for that is not a coincidence of timing.
What Actually Changes If You Already Run OpenTelemetry
For most teams already using OpenTelemetry, day to day nothing changes immediately. Where graduation does matter in practical terms:
What Is Still Genuinely Unsettled
Graduated status is about governance maturity, not about every corner of the project being finished. Two areas worth knowing about before you build long term plans around them:
Dan Gomez Blanco, who maintains OpenTelemetry’s End User Special Interest Group, put the overall picture simply: this graduation signals that OpenTelemetry is far from being an emerging standard anymore. The pieces still marked unstable are the exception inside a project that, on the whole, just cleared the same governance bar Kubernetes did.
Frequently Asked Questions
When did OpenTelemetry graduate from CNCF?
OpenTelemetry reached Graduated maturity status at the Cloud Native Computing Foundation on May 11, 2026. CNCF made the announcement public ten days later, on May 21, 2026, at the Observability North America Summit.
What does CNCF Graduated status actually mean?
Graduated is the highest of three maturity levels at CNCF, above Sandbox and Incubating. It requires a formal review by CNCF’s Technical Oversight Committee confirming a diverse set of committers across multiple organizations, a documented governance and security process, and proof of real production use at scale outside the companies that built the project. Kubernetes was one of the first projects to reach this level.
Does OpenTelemetry graduation change how the Collector or SDKs work?
No. Graduation is a governance and maturity milestone, not a software release. Existing OpenTelemetry Collector configurations and SDK instrumentation continue working exactly as they did before the announcement.
Is OpenTelemetry’s AI agent tracing support stable yet?
No. The generative AI and Model Context Protocol (MCP) semantic conventions are explicitly marked as under active development within the specification, even though the core project has graduated. Field names and span structures in that specific area can still change in future releases.
You can also read this article on Medium.
Related Articles:
OpenTelemetry Now Traces MCP Tool Calls: What It Means for AI Agent Observability
OpenTelemetry Collector Configuration: Full Setup Guide
How an AI Agent Was Tricked Into Leaking Its Own API Key: Inside the METR Security Incident
Leave a Reply