Jaeger

What it is

Jaeger is a distributed tracing system for monitoring and troubleshooting microservices-based architectures. It captures request flows across service boundaries, letting you see where time is spent, where errors originate, and how services depend on each other at runtime. It implements OpenTelemetry-compatible trace ingestion and is typically the tracing backend paired with OTel SDKs/Collectors instrumenting your application code.

Who builds it and why

Jaeger was originally built at Uber to solve their own microservices observability problem at scale, then donated to CNCF. It graduated in 2019, putting it in the same maturity tier as Prometheus and Kubernetes itself. With 489 contributors and active commits as recent as mid-2026, it's not a dead donated project — it has an ongoing maintainer base drawing from multiple companies, not just Uber anymore. The motivation is straightforward: as organizations decompose monoliths into services, someone has to own the "why is this request slow across 12 hops" problem, and Jaeger exists to answer that without vendor lock-in.

Production readiness signal

CNCF graduated status is the strongest signal here — that designation requires demonstrated production usage at multiple organizations, a documented governance process, and security audits. 22,956 GitHub stars and 489 contributors indicate a broad, active community rather than a single-vendor pet project. Latest release v2.19.0 shows a mature, iterating codebase (the v2 line represents a significant architecture shift toward native OpenTelemetry Collector integration, so check migration notes if you're coming from v1). Written in Go, consistent with the rest of the cloud-native tooling ecosystem — same operational profile you already know from Kubernetes and Prometheus. Founded date isn't publicly documented, but the project has been through multiple CNCF maturity levels and years of production hardening.

Who should use this

Teams running microservices architectures (10+ services communicating over the network) who need to debug latency and error propagation across service boundaries. If you're already instrumenting with OpenTelemetry and want an open-source backend rather than paying per-GB to a SaaS vendor, Jaeger is the default choice. It's also a fit if you need to self-host for compliance/data-residency reasons — traces often contain sensitive request data you may not want leaving your infrastructure.

Who should NOT use this

If you're running a monolith or a handful of services, distributed tracing overhead isn't worth it — logs and metrics will answer your questions faster and cheaper. Teams without dedicated platform/SRE capacity will struggle: Jaeger requires you to run and tune a storage backend (Elasticsearch, Cassandra, or object storage via the new v2 backends), and that operational burden is real and ongoing. If you want tracing, metrics, and logs unified in one pane of glass with minimal setup, a commercial APM (Datadog, Honeycomb, Grafana Cloud) will get you there faster — Jaeger is a component, not a full observability platform. Also skip it if you're not already committed to OpenTelemetry instrumentation; retrofitting tracing into an uninstrumented codebase is the actual hard problem, and Jaeger doesn't solve that part.

Alternatives

• Grafana Tempo — trace backend designed to be cheap at scale by skipping indexing and leaning on object storage; pairs naturally if you're already on the Grafana/Loki/Mimir stack.
• Zipkin — older, simpler distributed tracing system with a smaller feature set and slower release cadence than Jaeger; still viable for lightweight use cases.
• Datadog APM / Honeycomb — commercial SaaS options that bundle tracing with metrics, logs, and alerting out of the box, trading cost and data control for reduced operational overhead.

Pricing

Fully open source under Apache-2.0. No paid tier, no vendor. Your cost is entirely infrastructure (storage backend, compute for the collector/query services) and engineering time to run and maintain it.