Why we built our observability platform on open standards

The story of Chronosphere begins long before today, woven through choices, challenges, and quiet breakthroughs. It was forged in one of the most intense real-world observability challenges imaginable: Uber’s hypergrowth, as the company scaled to maintain one of the largest cloud native environments in the world. Years before “observability” became a recognized category, and well before Kubernetes took the world by storm, Chronosphere’s founders, Martin Mao and Rob Skillington, were already building the future.

They built an observability metrics engine at Uber called M3 (now an open source project), because nothing on the market could meet the scale, cost-efficiency, and reliability needs of a massive microservices architecture. That experience didn’t just influence Chronosphere, it became its foundation.

Today, Chronosphere champions open standards, data clarity over volume, and community-driven collaboration. The path from M3 to a global observability platform wasn’t just technical, it was a shift in how the industry thinks about telemetry.

For years, observability followed the “more data = more visibility” mindset. This approach leads to rising complexity, skyrocketing costs, and a growing gap between what engineers collect and what they can actually use.

At Uber, Martin and Rob saw the problem early:

• Cloud native architectures generate orders of magnitude more telemetry.
• Existing vendors weren’t built for this scale.
• Organizations were drowning in data they didn’t need, paying heavily for it.

The insight that sparked Chronosphere’s mission wasn’t about metrics or databases—it was about value:

Better observability isn’t about collecting everything. It’s about collecting the right things.

Every organization, not just hyperscalers, deserves observability designed for cloud native scale. Achieving this requires open standards, transparent data practices, and a community-focused ecosystem.

By focusing on open standards, smart data collection, and flexible architecture, Chronosphere empowers organizations to stay ahead of technological change and evolve observability as their systems grow.

When Mao and Skillington founded Chronosphere, they made a deliberate choice that went against conventional wisdom in enterprise software: build the entire platform on open standards, not proprietary protocols.

This wasn’t the easy path. Proprietary formats create natural moats — customers can’t easily leave, data becomes sticky, and switching costs stay high. It’s the playbook that built much of the legacy observability industry. Chronosphere could have followed it. Instead, the founders chose a different path: one that put customer control ahead of vendor control.

Here’s why they made that choice.

• They’d seen the cost of lock-in firsthand – At Uber, vendor lock-in meant slower adaptation, constant re-instrumentation, and technical debt that compounded year after year. The toll wasn’t just financial—it was organizational velocity.
• They knew the industry was at an inflection point – Cloud native architectures were exploding in complexity. Kubernetes was going mainstream. Open standards like Prometheus and OpenTelemetry were emerging as the common language. They could either build on that momentum or fight it.
• They believed trust would be the real competitive advantage – In a world where every vendor claims to be “open,” actually being open—ingesting, storing, querying, and exporting in open formats—would be the differentiator. Organizations would choose platforms they could trust not to trap them.
• They saw an opportunity others missed– While competitors added “Prometheus support” as a checkbox or built translation layers, they could build natively on open standards from day one. No retrofitting. No compromises. No proprietary query languages disguised as enhancements.

The conviction was straightforward: build the most powerful, scalable observability platform on open standards, and customers would choose freedom, performance, and flexibility over lock-in and limitations.

Five years later, that bet is paying off. Organizations choose Chronosphere because they can import existing Prometheus rules, migrate Grafana dashboards, and send data anywhere. That freedom creates accountability. Open standards aren’t just our philosophy—they’re our competitive advantage. Because when customers aren’t locked in, we have to earn their business every single day.

From day one, Chronosphere’s commitment to open source and open standards has been part of its architectural DNA. Today it’s more than a product, it’s a way of thinking about observability, anchored in three pillars:

1. A cloud native platform built for scale – metrics, logs, and traces designed for massive workloads, real-time visibility, and reliable operation at high scale without runaway costs.
2. Customer-first partnerships – helping teams migrate, control costs, and scale confidently.
3. Unwavering commitment to open source and open standards – enabling interoperability, ecosystem growth, and future-proof observability.

Built on M3, evolved with the ecosystem

At the core, Chronosphere is built on open standards optimized for cloud native scale.  Our  metrics engine is Prometheus compatible, built on M3 to deliver the performance, compression and cost-efficiency that raw Prometheus couldn’t achieve at planet-scale. For traces and logs, we use propose-built data stores designed for their unique characteristics; all unified under a single platform with native support for open standards (Prometheus, OpenTelemetry, Fluent Bit).

This means teams get:

• Native PromQL support – no translation layers, no proprietary query languages
• Prometheus remote-write compatibility – drop-in replacement for existing pipelines
• Kubernetes native architecture – built for the same environments that generate the telemetry

Staying ahead of standards, not behind them

As the observability landscape evolved, so did we, often ahead of the curve:

OpenTelemetry: When the industry converged on OpenTelemetry as the standard for distributed tracing and multi-signal telemetry, we didn’t retrofit support; we built native OTLP ingestion and processing into the platform. Today, Chronosphere provides first-class support for OpenTelemetry SDKs, collectors, and protocols, enabling seamless trace and log collection alongside Prometheus metrics.

Fluent Bit and Telemetry Pipeline: In 2024, we acquired Calyptia, founded by the creators and maintainers of Fluent Bit, the most widely deployed open source log processor in cloud native environments. This formed the foundation of Chronosphere Telemetry Pipeline (CTP), an enterprise-grade data routing platform built entirely on Fluent Bit. It lets teams collect, transform, and route telemetry from any source to any destination without vendor lock-in.

Perses: We became foundational contributors to Perses, the next-generation dashboard specification designed for modern observability. We’re not waiting for the future, we’re helping build it.

The result: Complete observability without proprietary constraints

Chronosphere today is a unified platform for metrics, logs, and traces where:

• Every ingestion point speaks open protocols (Prometheus, OpenTelemetry, StatsD, Fluent Bit)
• Every query runs in standard languages (PromQL, SQL for logs)
• Every dashboard can be exported in open formats
• Every data pipeline can route to any destination

This isn’t theoretical. Organizations running Chronosphere can:

• Import existing Prometheus recording rules and alerting rules with zero modification
• Migrate Grafana dashboards directly into the platform
• Send the same telemetry to multiple backends simultaneously for validation or hybrid architectures
• Export their data at any time in standard formats

Open standards aren’t a feature, they’re the foundation.

None of this happened by accident. It’s the direct result of Martin and Rob’s formative experiences at Uber and the principles they embedded into Chronosphere from the start.

Building an observability platform on open standards required more than technical decisions. It required a philosophical framework. Four core principles guided Chronosphere’s evolution from M3 at Uber to the platform it is today:

1. Real problems, not abstractions

M3 wasn’t built in a boardroom. It was built under pressure from real outages, real teams, and real production demands across Uber’s global footprint. The challenges solved there were about to hit the entire industry as Kubernetes became mainstream. Open sourcing M3 allowed the founders to contribute to a growing community and see the demand for scalable solutions firsthand. The need for cost-efficient observability built on open standards was universal, not an edge case.

2. Open source and open standards at the core

Chronosphere doesn’t treat open source as a checkbox or marketing tactic—it’s the foundation of everything we do. From ingestion to querying, we rely on open, vendor-neutral standards, ensuring users can integrate, evolve, and adopt new technologies without friction or lock-in.

When telemetry is ingested, stored, and queried via open formats and protocols, users gain:

• Full control over their data – switch tools, migrate backends, or integrate new systems without re-instrumenting
• Interoperability and ecosystem growth – third-party tools, exporters, and integrations plug in seamlessly.
• Future-proof architecture – as standards evolve (like the shift from Jaeger to OpenTelemetry), you adapt rather than rebuild

For organizations operating at scale, open standards aren’t a convenience; they’re a necessity. Only through open, community-governed tooling can we build systems that evolve as the industry evolves, adapt to new requirements, and integrate emerging technologies like AI-guided observability and next-generation compute.

3. Cloud native from day one

Unlike many observability tools built as extensions of legacy APMs, Chronosphere was born for microservices, containers, elastic infrastructure, and global, distributed systems. This gave it an advantage: no retrofitting was required, enabling smooth evolution as technology stacks change.

This native alignment means Chronosphere understands:

• High cardinality data from containerized workloads
• Dynamic infrastructure where services scale and disappear constantly
• Distributed tracing across hundreds of services
• Multi-cluster, multi-region, multi-cloud complexity

4. Value-centric data approach

Chronosphere helps organizations determine:

• What telemetry truly matters
• How it should be processed and stored
• How to reduce noise without losing signal

This value-first mindset helps companies achieve smarter, cost-efficient observability at scale. It’s not about collecting everything; it’s about collecting the right things.

We’re entering our next chapter with even greater resources and reach to advance our mission. The four principles that built Chronosphere: real-world problem solving, open standards, cloud native architecture, and value-first data; will continue to guide us but they’re expanding in scope and impact.

We’ll continue maintaining Fluent Bit, contributing to various open source projects, and championing the open standards that prevent vendor lock-in. We’ll keep building tools that help teams collect the right data, not all the data. And we’ll remain committed to the community-driven approach that’s defined us from the start.

As systems grow more complex and technology accelerates whether that is AI-driven applications to evolving security requirements; Chronosphere will continue pushing the boundaries of what observability can do. With open standards, smart data practices, and a community building the future alongside us, we’re ready for the next era of scale, intelligence, and resilience.