OpenTelemetry won the argument about how observability data gets into platforms. Now the industry needs to have the harder conversation: how does useful operational data get shared everywhere?
OpenTelemetry is winning.
Datadog supports it. New Relic supports it. Dynatrace, Splunk, Elastic and Grafana support it. Enterprises are standardizing around it. Instrument once, route the data wherever you need it, and avoid building your observability strategy around a proprietary ingestion format.
But there is an asymmetry hiding inside that success. Almost everyone wants to consume OpenTelemetry. Far fewer companies publish through it.
The observability industry has done a remarkable job creating an open standard for getting telemetry into platforms. It has done much less to make telemetry an open exchange mechanism between the companies that operate digital services and the customers who depend on them.
We think that needs to change, so we built APIContext to expose all our telemetry, everywhere.
OpenTelemetry won. But mostly in one direction.
76% of observability teams have invested in OpenTelemetry, according to Grafana. The CNCF describes OpenTelemetry as its second-highest-velocity project, with more than 24,000 contributors. This is not an emerging standard anymore. It is infrastructure.
But nearly all of the adoption conversation is about instrumentation and ingestion. Your application generates telemetry. Your collector processes it. Your observability platform consumes it. That model stops neatly at the edge of the organization.
What happens when the system you depend on belongs to somebody else? That is where things get much less standardized.
The industry standardized ingestion, not accountability
Look at the language observability vendors use around OpenTelemetry. The pattern is consistent: send us your traces. Send us your metrics. Send us your logs.
New Relic, for example, describes native OTLP ingest as its preferred way to send OpenTelemetry data into the platform.
Now compare that with how SaaS providers typically communicate the health of their own services. Status pages offer familiar mechanisms such as email notifications, webhooks, Slack or Teams integrations, and in some cases RSS or Atom feeds.
None of them advertise OpenTelemetry as a way for customers to consume operational data about the service itself.
Open standards are considered essential when vendors want your operational data. They are much less common when you want operational data from the vendor.
That asymmetry matters more as companies become dependent on increasingly complex chains of APIs, clouds, AI services, payment platforms, identity providers, data providers and other external systems.
A green status page is not telemetry. An incident email is not telemetry. A webhook saying "service degraded" is not telemetry. Those mechanisms are useful, but they are summaries created by the provider. They are not the same thing as having a machine-readable operational signal that can participate in your own observability system.
There are good reasons this is hard
Publishing telemetry outside your organizational boundary introduces legitimate concerns.
OpenTelemetry's own guidance puts responsibility for sensitive data on the implementer and warns that instrumentation can capture information that should not leave the system.
The W3C Trace Context specification similarly warns about blindly propagating trace information into external systems.
And anyone who has implemented observability at scale knows that the technology is often the easy part. Governance, ownership, consistency and organizational behavior are harder.
Those are real constraints. But there is another constraint that gets discussed less often: incentives.
Consuming telemetry creates obvious value for the company consuming it by encouraging stickiness. Publishing telemetry creates value primarily for the user. You get better visibility. Your SRE team gets faster incident correlation. Your compliance team gets better evidence. Your procurement team gets stronger data about whether you are meeting expectations.
Meanwhile, we take on the work of producing, securing and supporting the signal. We decided it was worth implementing anyway.
We built OpenTelemetry as an output, not an integration
When we added OpenTelemetry support to APIContext, we did not want another logo on an integrations page. We wanted OpenTelemetry to be one of the native ways our data leaves the platform. Every synthetic check APIContext runs can produce OpenTelemetry data. That includes the results of individual API calls and multi-step API workflows, with traces, metrics, logs and diagnostic information that can be routed into the systems customers already use.
Datadog. New Relic. Splunk. Dynatrace. Elastic. Your own OpenTelemetry Collector. The destination is not the important part to us. What’s important is that APIContext does not have to be the final destination.
That is a meaningful architectural distinction. A synthetic monitoring product can always build a better dashboard. It can add another graph, another incident screen, another proprietary query language. But the customer does not need another place to stare at telemetry. They need the signal to show up where the rest of their operational reality already lives.
Synthetic telemetry is especially suited to crossing boundaries
Production telemetry can be messy. Real traces and logs may contain customer identifiers, authentication information, request payloads, proprietary business data or other sensitive information. Sharing that data beyond the organization that generated it can create obvious security and privacy problems.
Synthetic traffic is different. You control the request and the data. You know what the monitor is executing.
That makes synthetic monitoring a particularly useful source of operational evidence that can be shared across organizational boundaries without automatically exposing the same categories of sensitive real-user data.
And the signal is valuable precisely because it comes from the outside. Your internal telemetry might say the service is healthy. Your provider might say their service is robust. Your synthetic monitor can answer a different question: Can our users actually use our services?
That is a question every organization increasingly needs to answer about the external systems it depends on.
Observability should not stop at the company boundary
Modern applications are assembled from dependencies. Your identity provider, payment processor, and delivery network are all somebody else's services. Your cloud APIs, AI models, mapping provider, communications platform and dozens of other critical components may all be operated by companies you do not control.
Yet most observability architectures still behave as though the interesting universe ends at your own infrastructure. If an external dependency is part of your application, evidence about that dependency belongs in your observability model. That does not mean the provider has to expose its internal traces. It means customers need useful, machine-readable signals they can correlate with everything else they know.
Open standards should work in both directions
OpenTelemetry has already made observability better by loosening the relationship between instrumentation and vendor. Now the industry should apply the same principle to the relationship between providers and customers. Open standards should not just make it easier for a vendor to consume your data. They should make it easier for you to consume theirs. That is the position we took with APIContext.
If you support an open telemetry standard, don't just consume it. Publish through it.
If you want to see how APIContext approaches this in practice, read our original OpenTelemetry announcement, our post on adding proactive API monitoring to your observability stack, the Partners and Developers page, or the API monitoring overview.