By ByteBot
OpenTelemetry just reached CNCF Graduated status — the same maturity tier as Kubernetes. The announcement dropped May 21, 2026, and if you are still paying a vendor to tell you what your own services are doing, that choice just got a lot harder to justify. Graduation means the project cleared an independent security audit, a formal governance review, and is now the second-most-active project in the entire 240-project CNCF ecosystem — behind only Kubernetes. This is not trivia. This is the moment OTel stops being aspirational and starts being the baseline.
What CNCF Graduation Actually Means
CNCF has three maturity levels: Sandbox, Incubating, and Graduated. Most projects never make it past Incubating. OpenTelemetry moved from Sandbox to Incubating in August 2021 and crossed to Graduated on May 11, 2026 — seven years after joining CNCF as a Sandbox project.
Graduation is not handed out for trajectory or promise. The project must pass a third-party security audit, demonstrate formal governance maturity, and show production adoption at scale. OpenTelemetry cleared all of it. CNCF CTO Chris Aniszczyk stated: “Attaining graduate status provides yet another indication that OpenTelemetry has become a de facto standard for collecting telemetry data.”
For developers this translates to one thing: any argument that OTel is still not ready for production is now dead. The foundation just certified it.
The Numbers Behind the Standard
Adoption data confirms what the governance review formalized. The OpenTelemetry JavaScript API logged over 1.36 billion downloads in the past twelve months. The Python API crossed 1.3 billion. Both set new monthly records in April 2026. The project counts 12,000 contributors from 2,800 companies. AWS, Google Cloud, and Azure all ship native OTLP support in their managed observability services — meaning you can route telemetry to the cloud provider without a proprietary sidecar anywhere in the chain.
In May 2026, Microsoft shipped VS Code 1.119, making Copilot Chat agent sessions emit OpenTelemetry data by default. That is not a coincidence timed to graduation week. That is Microsoft betting on OTel as the instrumentation standard across its entire developer tooling portfolio.
The Fourth Signal: Profiles Are Now in Alpha
Most developers know the three OTel signals: traces, metrics, logs. A fourth — profiles — entered public alpha in March 2026 and it changes what observability can do in production.
Continuous profiling gives you a low-overhead view of resource consumption and code execution across your running services, without code changes in most runtimes. Elastic donated its eBPF profiling agent to the project; it now runs as an OTel Collector receiver, slotting into your existing telemetry pipeline. The important feature is bi-directional correlation: you can link a profile to a specific trace or span. When a request goes slow you jump from the trace directly into the profiling data that explains why — no context switching between tools. Read the Profiles Alpha announcement for setup details.
OTel Is Now the Standard for AI Agent Observability
The GenAI Observability SIG’s semantic conventions define standard span attributes for LLM telemetry: model name, input and output token counts, finish reasons, tool calls and results. Datadog, Honeycomb, and New Relic already support them. LangChain, CrewAI, and AutoGen emit OTel-compatible spans natively or through instrumentation packages.
If you are building AI agents without tracing them with OTel, you are running multi-step LLM workflows blind to latency, cost, and failure modes. VS Code 1.119 proves the direction — even Microsoft’s AI tooling is now observable through OTel. The GenAI semantic conventions are still experimental, but the tooling is there and the standard is converging fast.
The Vendor Lock-In Decision Is Made
Datadog and Dynatrace both claim OpenTelemetry support. The detail that matters: Datadog accepts OTLP input and converts it to its own proprietary format on ingestion. Dynatrace’s OneAgent goes deep into your stack, and migrating off it means losing the automated context built around its proprietary data model. Both paths lead to the same place: your instrumentation is tied to a vendor contract.
The OTel alternative is not complicated. Instrument once using the OpenTelemetry SDK, route through the OpenTelemetry Collector, and export to any backend that speaks OTLP — which is now every major observability platform. Switch vendors without touching your application code. Starting a new project in 2026 and choosing a proprietary instrumentation agent is choosing technical debt from day one.
Three Things to Do This Week
- If you are already using OTel: Check which Collector version you are on. 0.152.1 shipped May 20. Review the Collector documentation for the latest pipeline options and confirm your exporters are current.
- If you are building AI agents: Read the GenAI semantic conventions now. Start emitting standard span attributes. The specification will stabilize and you want your instrumentation ahead of that, not scrambling to catch up.
- If you are on proprietary agents: Run an OTel Collector alongside your existing agent on one non-critical service. Compare what you get. The graduation announcement is a forcing function — use it to build the internal case for migration budget.
OpenTelemetry did not graduate because the cloud industry decided to be generous. It graduated because it won. The question now is when you treat it as the default — not whether.
