# OpenTelemetry vs Jaeger: Standard vs Tracing Backend

> OpenTelemetry vs Jaeger: vendor-neutral instrumentation standard vs a tracing backend and UI. How they fit together for distributed tracing.

Source: https://latchkey.dev/learn/tool-comparisons/opentelemetry-vs-jaeger  
Updated: 2026-06-26

OpenTelemetry is the vendor-neutral standard for generating and exporting telemetry; Jaeger is a backend and UI that stores and visualizes traces.

OpenTelemetry (OTel) is the CNCF standard - SDKs, APIs, and a collector - for instrumenting apps and exporting traces, metrics, and logs to any backend. Jaeger is a distributed tracing backend with storage and a query UI. They are complementary: OTel produces the data, Jaeger (among others) stores and displays it.

## Comparison

|  | OpenTelemetry | Jaeger |
| --- | --- | --- |
| Role | Instrumentation + export standard | Tracing backend + UI |
| Scope | Traces, metrics, logs | Traces |
| Vendor neutrality | Yes (export anywhere) | A backend |
| Storage | No (exports) | Yes |
| Best for | Standardized instrumentation | Viewing and querying traces |

## In practice

These are not really either/or: instrument your apps with OpenTelemetry, then send traces to a backend - which can be Jaeger. OTel future-proofs you against vendor lock-in; Jaeger gives you a mature open-source place to store and explore traces. Jaeger now embraces OTel ingestion directly, so the modern pattern is OTel SDKs feeding a Jaeger (or other) backend.

## Note

You can trace CI and build steps with OTel too. The builds run on CI runners; faster managed runners shorten them.

## Benchmark on your repository before choosing

Build-tool benchmarks published by vendors use repositories chosen to show a difference. Yours is the only one that matters, and both a cold and a warm measurement are needed because CI mostly runs cold.

```Terminal
# cold: no cache, the CI condition
rm -rf node_modules/.cache dist && time <tool> build

# warm: the local development condition
time <tool> build

# and the one people forget: incremental after a one-line change
echo "// touch" >> src/index.ts && time <tool> build
```

> Cold and warm can rank the two tools in opposite orders. Decide which one you are optimising for first: CI time is cold, developer feedback is warm and incremental.

## The verdict

They work together: use OpenTelemetry to instrument and export, and Jaeger (or another backend) to store and visualize traces. Standardize on OTel; pick Jaeger as one solid open-source tracing backend.

## FAQ

### OpenTelemetry vs Jaeger: Standard vs Tracing Backend?

OpenTelemetry (OTel) is the CNCF standard - SDKs, APIs, and a collector - for instrumenting apps and exporting traces, metrics, and logs to any backend. Jaeger is a distributed tracing backend with storage and a query UI. They are complementary: OTel produces the data, Jaeger (among others) stores and displays it.

### In practice?

These are not really either/or: instrument your apps with OpenTelemetry, then send traces to a backend - which can be Jaeger. OTel future-proofs you against vendor lock-in; Jaeger gives you a mature open-source place to store and explore traces.

### Note?

You can trace CI and build steps with OTel too. The builds run on CI runners; faster managed runners shorten them.

### Which should I choose?

They work together: use OpenTelemetry to instrument and export, and Jaeger (or another backend) to store and visualize traces. Standardize on OTel; pick Jaeger as one solid open-source tracing backend.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt