Observability and OpenTelemetry History and Timeline - Competing Specifications, a Foundation Merger, and the Path to a Single Standard

Q: Was OpenTelemetry created from scratch?

No. The official documentation states: OpenTelemetry is a Cloud Native Computing Foundation (CNCF) project that is the result of a merger between two prior projects, OpenTracing and OpenCensus. ⇒ It was not created as a third, entirely new specification, but rather is the result of merging two existing, parallel efforts. References: What is OpenTelemetry?

Observability and OpenTelemetry History and Timeline - Competing Specifications, a Foundation Merger, and the Path to a Single Standard

First Published: 2026-09-07
Last Updated: 2026-09-07

Anyone who has ever had to rewrite instrumentation code has likely faced the same question: why twice? Vendors' libraries were replaced with a standard API, only for that standard itself to later be renamed. Neither rewrite altered the behavior of the application in the slightest. The only thing that changed was who decided how instrumentation should be implemented.

This article explores the history and timeline of observability, specifically how the standards for instrumentation have evolved. It is not a history of product features, but rather the path along which two specifications stood side by side, were folded into one instead of one defeating the other, and finally led a cloud provider to stand its own libraries down.

From Two Specifications to One - How Observability Instrumentation Converged

What sets this story apart from the histories of other tools is the fact that the turning point was a confluence rather than a split. It is not a story of one project splitting into two, nor of one being abandoned due to changes in licensing. Instead, two independently developed specifications came together under a single foundation. As a result, developers around the world had to rewrite their instrumentation twice: once for their own sake, and once for the merger.

This article does not evaluate the merits of any particular instrumentation library. It does not offer opinions on which library is superior or where users should migrate. It also avoids judging the decisions made by companies or communities. Instead, it focuses on documenting what primary sources stated, and when. Furthermore, it refrains from speculating on reasons when official documentation does not provide them.

All information presented in this article was verified as of 2026-09-06.

Related articles on hidekazu-konishi.com:

Background and Method of Creating the Observability and OpenTelemetry Timeline

What Counts as a Turning Point Here

This timeline is not exhaustive. The set of observability products and instrumentation libraries is vast, and listing every version would not reveal the reasons why instrumentation had to be rewritten twice. We have only included the following three types of rows:

Rows where authority over instrumentation practices changed — Rows indicating a change in who defines the API. This includes the initial specification launch, acceptance by a foundation, the merger, and archival.
Rows where a specification became the default implementation — Rows marking the shift from something that could be written to something written by default. This includes the declaration of a stable release and the recommendation of a propagation format.
Rows where the support status changed — Rows indicating a transition to maintenance-only, archival, or graduation.

Rows for feature additions are generally excluded. The history of features for each product can be found in their respective official release notes and changelogs. However, we have made exceptions for feature additions that directly influenced the decision of which specification to use for instrumentation. An example of this is November 21, 2024, when AWS X-Ray added support for OTLP endpoints.

The Primary Sources This Article Used

Each row includes the URL for the corresponding primary source. The following categories of sources were utilized:

Official Websites and Blogs of the Projects: opentelemetry.io, opentracing.io, opencensus.io, prometheus.io, zipkin.io
Foundation Records: Project pages, announcements, and blogs from the Cloud Native Computing Foundation. Note that project pages contain information related to the date of project maturity, which is distinct from the publication dates of blog posts.
Standardization Body Recommendations: W3C Trace Context
Academic Papers and Technical Reports: Google's Dapper
Vendor Official Blogs: Google Open Source Blog, Twitter Engineering Blog, Grafana Labs
AWS Documentation and Official Blogs: AWS X-Ray document history, support timeline, AWS Cloud Operations Blog
Source Repositories: Release tags in the OpenTelemetry specification repository.

⛔ Secondary media and summary articles were not considered primary sources. There are many secondary articles on this subject, and a good number of them round the status off. Regarding AWS X-Ray maintenance notifications, discrepancies have been observed between information presented in secondary articles and the original primary source material.

Why This Timeline Records a Merger Rather Than a Split

There are different ways in which the evolution of tools can unfold. Sometimes, ownership of names changes, and other times, terms of availability are altered. What happened with the instrumentation related to observability was neither of those things.

Between 2016 and 2019, two sets of instrumentation specifications, both promoting vendor neutrality, existed side by side. ⛔ The two were not, however, on the same footing. OpenTracing was a CNCF project, while OpenCensus was developed on GitHub under Google's leadership. Only one of the two sat under a foundation's governance. Both were nonetheless trying to solve the same problem. From the users' perspective, the issue was not about which was better, but rather that two existed. Instrumentation developed using one set of specifications could not directly connect to the analytical infrastructure that relied on the other.

This timeline records the path by which the foundation folded that situation together through mediation. ⛔ The foundation brokered between the project it held and one it did not. One side did not fail and disappear. Instead, both moved to read-only status, a successor took on the role of bridging the two, and that successor became a CNCF project.

⚠ The asymmetry leaves a trace later in the timeline. OpenTracing was archived through the foundation's own procedure, and the foundation announced it. OpenCensus had no such procedure and finished by closing its own repositories. A foundation can only archive the projects it holds.

⚠ This article calls the path a merger, but that is not an evaluative term. It follows the primary sources, which use the word merger.

The Trigger Column

Each row in the timeline is assigned a trigger type. The values used are as follows:

Paper — Rows representing documents or technical reports that have been publicly released.
Launch — Rows indicating the start of a project or specification.
Foundation — Rows representing instances where a foundation accepted, matured, or archived a specification.
Merger — Rows where two specifications were folded into one.
Standard — Rows where a standards body issued a recommendation, or where a specification reached a stable version.
Lifecycle — Rows indicating a change in the provision status.
License — Rows indicating a change in the licensing terms.

What This Article Leaves to Other Articles

This article does not cover how to write instrumentation. Configuring OTLP, writing PromQL queries, and migrating from the X-Ray SDK are all held by earlier articles.

Implementing OTLP ingestion, PromQL, and migration from the X-Ray SDK on AWS — This is covered in OpenTelemetry-Native Observability on AWS. In particular, that article dedicates a section to reading the AWS X-Ray maintenance notice accurately.
Design principles and terminology for observability — Covered in AWS Observability Architecture Guide and AWS Observability Glossary.
How to handle stability on a signal-by-signal basis in implementation — OpenTelemetry GenAI Semantic Conventions Implementation Guide includes a section on this topic.
The history and evolution of Amazon CloudWatch features — AWS History and Timeline regarding Amazon CloudWatch provides this information.
The lineage of CI/CD tools and the role of the foundation within that ecosystem — CI/CD Tools History and Timeline covers this.
An analysis of what a license transition entails — This article only mentions Grafana Labs' license change as a single row in a timeline, without delving into the specifics of the license terms. Terraform and OpenTofu History and Timeline covers this.

Observability and OpenTelemetry Historical Timeline (Updates from April 2010)

The following is a timeline of instrumentation standards for observability. The rows are listed in chronological order, with a link to the primary source material for each.

Use the following index to jump to a specific year:

2010 - A paper on the design of production tracing is published.
2012 - The implementation of the paper is released externally.
2016 - The foundation accepts instrumentation APIs.
2017 - The tracing implementation is incorporated into the foundation.
2018 - A second specification emerges, and coexistence begins.
2019 - The foundation merges the two specifications into one.
2021 - Tracing reaches a stable release, and propagation becomes a Recommendation.
2022 - One of the specifications is formally archived.
2023 - The repository for the other specification is closed.
2024 - The cloud provider opens an endpoint for the standard.
2025 - The provider announces the maintenance plan for its own libraries.
2026 - The provider's own libraries go to maintenance only, and the standard graduates.

2010-2012 - Tracing Is Built in Production, Then Published

During this period (2010-2012), distributed tracing was not yet a standard; it was an internal system within a single company. One company published a paper detailing its design, and another company implemented that design and released it externally. The question of who would determine the standards for instrumentation had not yet been raised.

Date	Project	Trigger	Summary
2010-04	`Dapper`	`Paper`	Google published a technical report on Dapper. The report opens with the line `Google Technical Report dapper-2010-1, April 2010` and describes the design of a distributed tracing infrastructure running in Google's production environment. The report outlines the goals as `low overhead, application-level transparency, and ubiquitous deployment on a very large scale system`. ⇒ Nearly all subsequent implementations have taken these three points as their starting point. The report also notes key decisions that enabled its operation at this scale, specifically `the use of sampling and restricting the instrumentation to a rather small number of common libraries`. ⚠ Dapper itself is not the starting point. The report cites `Magpie` and `X-Trace` as prior research, acknowledging conceptual similarities. ⚠ The primary source states the date only to the month, so this row keeps that level of precision. References: Dapper, a Large-Scale Distributed Systems Tracing Infrastructure
2012-06-07	`Zipkin`	`Launch`	Twitter open-sourced Zipkin. The announcement describes the tool as collecting latency data from multiple services involved in requests to Twitter's API. ⇒ This was the first example of another company implementing and releasing externally, inspired by the Dapper paper. The announcement states that this implementation began as an internal Hack Week project, built for Thrift, demonstrating a direct lineage from the paper. ⚠ The post is dated `Thursday, 7 June 2012`, and it states that Zipkin was open sourced under the APLv2 license. References: Distributed Systems Tracing with Zipkin

2016-2018 - Two Specifications Arrive, and They Do Not Agree

During the period of 2016-2018, two specifications emerged, both aiming for vendor-neutral instrumentation. One defined only the API, while the other encompassed the library and destination endpoints as well. This difference in design philosophy is why the merger later needed a bridge between the two.

Date	Project	Trigger	Summary
2016-05-09	`Prometheus`	`Foundation`	Prometheus was accepted into the Cloud Native Computing Foundation at the Incubating maturity level. It is the second project, following Kubernetes. This row is not about the instrumentation API, but it matters later in the timeline. Regarding metrics, established collection practices already exist, and any new standards will need to coexist with them. References: Prometheus
2016-10-11	`OpenTracing`	`Foundation`	OpenTracing was accepted into the Cloud Native Computing Foundation. The announcement stated that this specification provides `standard, consistent APIs in many languages` and offers developers `clean, declarative, testable, and vendor-neutral instrumentation`. ⛔ What matters here is that OpenTracing is an API, not an implementation. It is up to the users and individual vendors to decide which libraries to use for collection and where to send the data. This design choice will differentiate it from another specification that will emerge two years later. References: OpenTracing / OpenTracing: turning the lights on for microservices
2017-09-13	`Jaeger`	`Foundation`	Jaeger was accepted into the Cloud Native Computing Foundation at the Incubating maturity level. It is a distributed tracing implementation originally released by Uber. ⇒ At this point, the foundation held both the API specification and a separate tracing implementation. References: Jaeger
2018-01-17	`OpenCensus`	`Launch`	Google launched OpenCensus. The announcement described it as `a vendor-neutral open source library for metric collection and tracing`. ⛔ The word is `library`, not `API`. This specification included both metric collection and tracing, and also handled output to various destinations. The announcement records the backends supported at launch as `OpenCensus currently supports Prometheus, SignalFx, Stackdriver and Zipkin`. ⇒ This resulted in a situation where two specifications, both promoting vendor-neutral instrumentation, were operating in parallel. References: OpenCensus: A Stats Collection and Distributed Tracing Framework
2018-08-09	`Prometheus`	`Foundation`	Prometheus graduated from the Cloud Native Computing Foundation. It is the second project to graduate, following Kubernetes. ⚠ This row is included as a precedent showing that the foundation's maturity levels do move all the way through. It provides the yardstick for reading what it means when the same foundation graduates another project later in this timeline. References: Cloud Native Computing Foundation announces Prometheus graduation / Prometheus

2019-2021 - A Foundation Folds Them Together

This section is the core of the article. The two specifications that had stood side by side did not end with one prevailing over the other. Instead, both yielded to the successor, and the successor took on the role of bridging the gap between them. It then took an additional two years for that successor to become the established implementation.

Date	Project	Trigger	Summary
2019-05-07	`OpenTelemetry`	`Foundation`	OpenTelemetry was accepted into the Cloud Native Computing Foundation at the Sandbox maturity level. This is the acceptance date recorded on the foundation's project page. ⚠ This date is two weeks earlier than the public announcement date. The foundation's record and the announcement article are separate pieces of information, and this article places both as separate rows. References: OpenTelemetry
2019-05-21	`OpenTelemetry`	`Merger`	The merger of OpenTracing and OpenCensus was announced. The foundation's blog states, `OpenTracing and OpenCensus are merging to form OpenTelemetry, which is now a CNCF sandbox project`. ⛔ This was a merger, not an adoption or absorption of either project. The post outlines a migration strategy, maintaining backward compatibility for both projects through software bridges, and aims to minimize the period where OpenTelemetry, OpenTracing, and OpenCensus are being co-developed, as `Minimizing the time where OpenTelemetry, OpenTracing, and OpenCensus are being co-developed: we plan to put OpenTracing and OpenCensus into "readonly mode" before the end of 2019.` ⇒ The deadline for transitioning the merged projects was in effect at the time of the merger. References: A brief history of OpenTelemetry (so far)
2019-10-31	`Jaeger`	`Foundation`	Jaeger graduated from the Cloud Native Computing Foundation. This occurred approximately five months after the merger announcement. ⚠ The focus of the merger was the instrumentation specification, not the tracing implementation itself. Jaeger was maturing as an independent project, not being absorbed into the merger. Failing to recognize this distinction could lead to the impression that a number of observability projects were tidied up all at once in 2019. References: Cloud Native Computing Foundation announces Jaeger graduation
2021-02-10	`OpenTelemetry`	`Standard`	OpenTelemetry specifications reached version v1.0.0. The release notes state, `This version of the OpenTelemetry specification includes a stable release of the Tracing API and Tracing SDK components`. ⛔ Only tracing was considered stable; the entire specification was not. The same release removed the metrics SDK specification, citing a desire to avoid confusion, and noted that the metrics API specification was not recommended for implementation at that time. ⇒ This indicates that different components had varying levels of maturity, a design consideration evident from this point forward. References: Release v1.0.0
2021-04-20	`Grafana`	`License`	Grafana Labs changed the licenses for Grafana, Loki, and Tempo from Apache License 2.0 to AGPLv3. ⚠ This row places the event as one event in the observability ecosystem and does not go into the structure of the license change. The analysis of the license clauses is covered in Terraform and OpenTofu History and Timeline. References: Grafana, Loki, and Tempo will be relicensed to AGPLv3
2021-08-20	`OpenTracing`	`Foundation`	OpenTracing's maturity level moved to Archived. This is the date recorded on the foundation's project page. ⛔ However, the public announcement of this transition occurred five months later. This row places both as separate rows and records the discrepancy here. References: OpenTracing
2021-08-26	`OpenTelemetry`	`Foundation`	OpenTelemetry's maturity level moved to Incubating. ⚠ This occurred six days after the previous row. In the month when the side that was folded in moved to Archived, the side that folded it raised its maturity by one level. ⚠ While the proximity of these two dates is noteworthy, no documentation from the foundation was found that directly linked the two events. This row avoids making assumptions about a connection. The announcement of the same day refers to the pre-merger OpenTracing as `a CNCF incubating project`, which shows that it was OpenTracing that sat under the foundation's governance. References: OpenTelemetry / OpenTelemetry becomes a CNCF incubating project
2021-09-30	`Amazon Managed Service for Prometheus`	`Lifecycle`	Amazon Managed Service for Prometheus became generally available. The announcement stated, `We are excited to announce that the Amazon Managed Service for Prometheus is now Generally Available.` ⇒ In the metrics space, the adoption of a standard took a different path than the instrumentation merger. Rather than merging an API, a managed service directly adopted existing, widely used collection practices and query languages. References: Amazon Managed Service for Prometheus is now Generally Available
2021-11-23	`W3C Trace Context`	`Standard`	The W3C published Trace Context as a Recommendation. The document states that it is `W3C Recommendation 23 November 2021`. The specification describes `traceparent` as a way to identify requests within a tracing system and represent its position `in a portable, fixed-length format`, while `tracestate` extends it `with vendor-specific data represented by a set of name/value pairs`. ⇒ While an API was merged, a standards body simultaneously finalized a format for propagating context across processes. These are distinct layers; portability is not achieved with either alone. References: Trace Context

2022-2024 - The Standard Becomes the Default

During this period (2022-2024), the standard shifted from being an option to becoming the default. The two sides that had been folded together began to close sequentially, while the cloud service provider opened the standard interface.

Date	Project	Trigger	Summary
2022-01-31	`OpenTracing`	`Foundation`	The foundation announced that OpenTracing had been archived. The Technical Oversight Committee approved it. ⛔ As noted above, the foundation's project page records August 20, 2021, as the date of the move to Archived, which is five months before this announcement. This article does not claim that either date is definitively correct. ⚠ The archive represents a cessation of activity, not a prohibition on usage. According to the foundation, archived projects can come back through the standard proposal process. References: CNCF Archives the OpenTracing Project / OpenTracing
2022-05-19	`OpenTelemetry`	`Standard`	Metrics were declared available and made generally available in AWS distributions. An AWS article states, `in the OpenTelemetry upstream we have declared metrics ready for use this week`, and also notes `At the end of 2021 we made traces in OpenTelemetry generally available (GA)`, indicating that traces had reached that milestone earlier. ⛔ The timing of availability differed for each signal type. Traces, metrics, and logs did not all stabilize simultaneously; rather, they progressed sequentially. ⇒ Therefore, there is no single point in time when "OpenTelemetry" can be definitively said to be stable. References: AWS Distro for OpenTelemetry is now generally available for metrics
2023-07-31	`OpenCensus`	`Lifecycle`	The OpenCensus repository was archived. The official website states that `All OpenCensus Github repositories, except census-instrumentation/opencensus-python, will be archived on July 31st, 2023.` ⚠ One exception is explicitly stated. The same website describes the outcome of the merger as, `OpenCensus and OpenTracing have merged to form OpenTelemetry, which serves as the next major version of OpenCensus and OpenTracing.` ⇒ The fact that the side that was folded in refers to the resulting project as the "next major version" suggests that this merger was not a defeat. References: OpenCensus
2023-10-25	`AWS X-Ray`	`Standard`	AWS X-Ray began supporting trace IDs generated using OpenTelemetry or any framework that conforms to the W3C Trace Context specification. The document history records this change as, `X-Ray now supports trace IDs created via OpenTelemetry or any other framework which conforms to the W3C Trace Context specification`. ⇒ This represents a shift where the provider adopted a standard format rather than relying solely on its own proprietary identifier. References: Document History for AWS X-Ray
2024-11-21	`AWS X-Ray`	`Standard`	AWS X-Ray added support for the OpenTelemetry Protocol endpoint. Transaction Search was also added on the same day. ⇒ This is the row where an endpoint for sending traces in the standard format opened on the provider's side. It is now possible to instrument using a standard approach and then select the provider's service as the destination. ⚠ Implementation and configuration details are covered in existing documentation. References: Document History for AWS X-Ray

2025-2026 - A Cloud Provider Stands Down, and the Standard Graduates

Two things happened in this period. A provider moved its own instrumentation library into a maintenance-only state, and the standard that came out of the merger graduated from the foundation. The first is the story of one provider; the second is the point at which the arc of the merger closes.

Date	Project	Trigger	Summary
2025-06-13	`AWS X-Ray`	`Lifecycle`	AWS added a section to the documentation detailing the migration from X-Ray to OpenTelemetry. The document history records this as `Migrating from X-Ray to OpenTelemetry`. ⚠ At this point, this was an addition of migration guidance, not an announcement of end-of-support. References: Document History for AWS X-Ray
2025-08-22	`AWS X-Ray`	`Lifecycle`	AWS added an end-of-support notice for the X-Ray SDKs and Daemon to the documentation. The document history records it as `On February 25th, 2027, AWS X-Ray will discontinue support for AWS X-Ray SDKs and Daemon.` ⛔ This is the only place in the currently published documentation that names an end date. The support timeline, updated three months later, lists the end date as `N/A`, so the two do not agree. This article records both, along with their respective dates, without determining which one takes precedence. References: Document History for AWS X-Ray
2025-11-14	`AWS X-Ray`	`Lifecycle`	AWS announced the migration of the X-Ray SDK and Daemon to OpenTelemetry on the official blog. The article clarifies that the migration applies only to the SDK and Daemon, stating that `The AWS X-Ray service remains fully supported and continues to be enhanced with new features like native OpenTelemetry support and Amazon CloudWatch Transaction Search.` ⛔⛔ Only the SDK and Daemon are being transitioned; the AWS X-Ray service itself is not. The same article also states that, even during the transition, X-Ray will continue to receive and process traces from existing SDKs and Daemons. References: AWS X-Ray SDKs/Daemon migration to OpenTelemetry
2025-11-26	`AWS X-Ray`	`Lifecycle`	AWS updated the documentation with the support timeline for the X-Ray SDK and Daemon. The document history records this update. ⚠ This article treats the currently published support timeline as authoritative. References: Document History for AWS X-Ray
2026-02-25	`AWS X-Ray`	`Lifecycle`	The X-Ray SDK and Daemon have entered a maintenance phase. The support timeline, presented as a two-row table, records both the end of general availability and the start of maintenance on this date, stating that `AWS will limit X-Ray SDK and Daemon releases to address security issues only. The SDKs/Daemon will not receive new feature enhancements.` ⛔ The maintenance row in the same table lists the end date as `N/A`. ⚠ An end date in a later year does not appear in the currently published support timeline, in the SDK repositories, or on the official blog. Where it does appear is the document history, in the end-of-support notice dated 2025-08-22. ⛔ The two AWS sources do not agree. This article records both, without determining which one takes precedence. References: X-Ray SDK and Daemon Support timeline
2026-05-11	`OpenTelemetry`	`Foundation`	OpenTelemetry's maturity level moved to Graduated. This is the date recorded on the foundation's project page. ⇒ A project accepted at the Sandbox level in 2019 reached the highest maturity level seven years later. References: OpenTelemetry
2026-05-21	`OpenTelemetry`	`Foundation`	The graduation was publicly announced. The project's blog details the history since the merger, stating that `Since the merger of OpenTracing and OpenCensus, thousands of contributors, maintainers, end users, and organizations have helped shape OpenTelemetry`. ⚠ The merger was also announced on May 21st. Seven years after the initial merger announcement on 2019-05-21, the result of that merger was publicly announced as graduation. ⚠ The primary source does not mention the coinciding dates. This article simply records the coinciding dates without speculating on any intent. References: OpenTelemetry is a CNCF Graduated Project / Cloud Native Computing Foundation Announces OpenTelemetry's Graduation

Current Overview of How Observability Instrumentation Is Governed Today

The Three Triggers That Have Actually Bent This Line

Looking at the historical timeline, the factors that ultimately shifted the trajectory of the instrumentation system can be narrowed down to three. None of these were due to technical superiority.

The existence of two specifications — The period from 2016 to 2019, where both existed concurrently, exemplifies this. The issue for users was not which was better, but rather the fact that there were two.
The foundation serving as a mediation point — ⚠ Only one of the two sat under the foundation's governance, but the foundation brokered between that one and the other, folding them into a successor rather than eliminating either.
The decision by a provider to stand its own instrumentation down — After the standard became the established implementation, a provider moved its own libraries to a maintenance-only status. ⚠ This timeline records one such provider.

⚠ The third point was not the result of the standard forcing a decision on the provider. Primary sources record it as the provider's own decision. This article does not offer any further causal explanations.

What a Merger Does That a Fork Does Not

When a project forks, users are faced with a choice. They must decide which side to support, or perhaps maintain both. A merger does the opposite: it removes the choice, but demands a rewrite in exchange.

This difference is evident in where the burden of migration is felt. With a fork, assets from the unselected side gradually become unusable. In a merger, both sets of assets initially pass through a bridge, which will eventually be removed. This is why the 2019 announcement took the shape it did: it kept backward compatibility through a software bridge, and in the same breath set a deadline for moving both to read-only.

Note that a merger does not eliminate the need for rewriting. In fact, instrumentation written during the period when the projects existed alongside each other will require migration, regardless of which side it is moved from. This is the primary reason why instrumentation ended up needing to be rewritten twice.

Who Writes the Instrumentation - From Vendor SDKs to Zero-Code Agents

Who Writes the Instrumentation Now

When re-examining the timeline through the lens of who writes the instrumentation code, a different pattern emerges. The responsibility for writing instrumentation code has shifted in three stages.

The stage where users call libraries provided by vendors — Each analytical platform had its own libraries, and switching platforms meant rewriting code.
The stage where users call libraries that adhere to a neutral specification — The calling mechanism was standardized, allowing users to simply replace the destination endpoint.
The stage where users do not write the calling code — Instrumentation is integrated into the execution environment, becoming effective without any code changes.

⚠ A later stage did not erase the one before it. All three still coexist today. ⚠ Furthermore, the implementation status varies by language, depending on the specific signal. The current state is documented in the official Specification Status Summary, and this article does not reproduce that content.

Reading a Maintenance Notice Without Rounding It Off

⛔⛔ The row for February 25, 2026, is the one most likely to be misinterpreted in this timeline.

The AWS X-Ray SDK and Daemon have entered the maintenance phase. The AWS X-Ray service itself is not affected. The official blog states that The AWS X-Ray service remains fully supported and continues to be enhanced, and that even while in maintenance, it will continue to receive and process traces from the existing SDK and Daemon.

Writing that "X-Ray has entered maintenance" without this distinction is factually incorrect. This crucial distinction is often the first to be lost when trying to summarize the information.

⚠ The two AWS sources do not agree on the end date. The maintenance row in the support timeline lists the end date as N/A, while the document history carries an end-of-support notice, dated 2025-08-22, stating that On February 25th, 2027, AWS X-Ray will discontinue support for AWS X-Ray SDKs and Daemon. ⛔ This article does not determine which of the two takes precedence. It records what each source says and the day each was published.

How to read this notice in practice is covered in a dedicated section of an earlier article. For the migration decision, the order in which to act, and what actually functions as a deadline, see OpenTelemetry-Native Observability on AWS. This article stays with placing the event as a single row in the timeline.

What Graduation Does and Does Not Mean

Graduation is the foundation's level of maturity, and is not an indicator of adoption rate. The foundation's stages are Sandbox, Incubating, and Graduated. OpenTelemetry moved through them in that order, reaching Sandbox in 2019, Incubating in 2021, and Graduated in 2026.

⚠ This article does not discuss adoption rates or market share. The official statement refers only to changes in maturity level, and does not reflect usage figures. ⛔ This article does not treat share figures from secondary research as primary sources.

⚠ Graduation is a separate matter from the stability of individual signals. The specification includes components that have reached a stable version, as well as those still under development. As the timeline shows, tracing reached a stable version in 2021, while metrics were declared ready for use in 2022 — these milestones did not occur at the same time. It is inaccurate to broadly state that "OpenTelemetry is stable" by combining these two aspects. The current status is documented on the official Specification Status Summary, and may change over time. ⛔ This article does not reproduce that information. Doing so would quickly render the article outdated.

Frequently Asked Questions about Observability and OpenTelemetry History

Was OpenTelemetry created from scratch?

No. The official documentation states:

OpenTelemetry is a Cloud Native Computing Foundation (CNCF) project that is the result of a
merger between two prior projects, OpenTracing and OpenCensus.

⇒ It was not created as a third, entirely new specification, but rather is the result of merging two existing, parallel efforts. References: What is OpenTelemetry?

What was the actual difference between OpenTracing and OpenCensus?

The scope of their designs differed. OpenTracing was a specification providing a consistent API across multiple languages, but it left the decision of which libraries to use for collection and where to send the data to external components. OpenCensus, on the other hand, was released as a library that included both metrics collection and tracing, and handled the output to the destination. The key difference was not about which had superior features, but rather about how far the standard should reach.

Did one of them win?

No. Both yielded to the successor. The 2019 merger announcement set out a plan to move OpenTracing and OpenCensus to read-only status before the end of 2019, so as to minimize the period during which all three were developed in parallel. The official OpenCensus website refers to the successor as the next major version of OpenCensus and OpenTracing.

Is AWS X-Ray discontinued?

No. It is the X-Ray SDK and Daemon that have entered a maintenance phase, not the service itself. The official blog states that The AWS X-Ray service remains fully supported and continues to be enhanced. ⚠ The two AWS sources do not agree on the end date for the SDK and the Daemon. The support timeline gives the end of maintenance as N/A, while the document history carries a notice dated August 22, 2025 that names February 25th, 2027.

Does OpenTelemetry's graduation mean the specification is entirely stable?

No. Graduation signifies the foundation's level of maturity, and is separate from the stability of each part of the specification. The specification includes components that have reached a stable version, as well as those still under development, and the status varies for each signal. Therefore, it is not possible to broadly state that "OpenTelemetry is stable." To read the current status, refer to the official Specification Status Summary.

Where does W3C Trace Context fit in?

It operates on a different layer. OpenTelemetry defines the instrumentation APIs and the mechanisms for transmitting data. W3C Trace Context defines the format of the HTTP headers used to propagate context across processes. If instrumentation is common, but the propagation format is not aligned, tracing across boundaries will not connect. This format became a W3C Recommendation on November 23, 2021.

Why does this timeline include a license change?

Grafana Labs relicensed Grafana, Loki, and Tempo in 2021, and that is placed as a single row, as one event in the observability ecosystem. The change belongs in the timeline, but the structure of a license transition itself is not the subject of this article. ⇒ The analysis of the clauses is left to a separate article.

Why does this timeline not rank the tools?

This article traces the path of how the conventions for instrumentation have been established. Which implementation is faster, or which one to choose, varies depending on the point of reference and the requirements. ⚠ Furthermore, it does not offer evaluations of the decisions made by individual companies or communities. Simply documenting the order in which events occurred is different from assessing their merits or demerits.

Summary

Instrumentation has a unique lineage, distinct from other tools. Instead of branching, it involved a merging of paths.

In 2016 a specification that was an API entered the foundation, and in 2018 a separate specification was published as a library. The issue was not about superiority or inferiority; it was simply the existence of two separate options. On 2019-05-21, the foundation folded them together, setting a deadline for transitioning both to read-only status. The side that was folded in closed in turn, in 2021 and in 2023, while the successor reached a stable release for tracing in 2021 and the foundation's highest maturity level on 2026-05-11.

During this process, the work of writing instrumentation was performed twice. First, it transitioned from a vendor's library to a neutral specification, and second, it moved from the two parallel specifications to the merged successor. In both instances, the behavior of the applications remained unchanged.

The provider's own moves follow behind that path. AWS X-Ray accepted the standard identifier format in 2023, opened an endpoint for the standard in 2024, and moved its own SDK and Daemon into maintenance on 2026-02-25. ⛔ Note that maintenance applies to the SDK and Daemon; the AWS X-Ray service itself continues to be fully supported. This article states the distinction in several places, because it is the first thing to collapse when the story is shortened.

⚠ This article does not discuss adoption rates. The official documentation only states that the maturity level changed, not how widely it is used. ⚠ The stability of the individual signals cannot be written as a single blanket statement either. The state differs depending on when it is consulted, so this article leaves it to the official status summary.

The reason instrumentation had to be rewritten twice was not on the technical side. There was a period where two different answers existed regarding the scope of the standard. The foundation folded them together, and it took seven years for the result to reach the highest maturity level.

This area continues to evolve. This article will be updated to reflect those changes.

There are other articles on related subjects:

References:
Tech Blog with curated related content

Written by Hidekazu Konishi