● Beta — KubeEra is in active development. Profiles are live; AI-perception measurement is rolling out.
KubeEra
Z

Zipkin

Observability
Open source · Apache-2.0

Zipkin is a distributed tracing system.

updated 2026-07-01

Zipkin

What it is

Zipkin is a distributed tracing system. It collects timing data from services to help you figure out where latency is coming from in a request that hops across multiple processes — the classic "why is this call slow" problem in microservice architectures. It has a collector, a storage layer (with pluggable backends like Cassandra, Elasticsearch, or in-memory for testing), a query API, and a web UI for visualizing trace timelines and dependency graphs. Instrumentation is handled through Brave (its Java tracer library) or via OpenTracing/OpenTelemetry-compatible reporters that emit spans in Zipkin's format (B3 propagation headers being the most recognizable artifact it introduced).

Who builds it and why

Zipkin originated at Twitter, modeled on Google's Dapper paper, to deal with debugging latency across Twitter's service graph as it decomposed its monolith. It's now maintained as an independent open-source project (openzipkin org) with 142 contributors and steady commit activity through 2026. There's no single vendor behind it — it's a community-maintained infra tool, not a commercial product with a company driving the roadmap. That's both its strength (no lock-in, no upsell pressure) and its limitation (no dedicated support org backing it).

Production readiness signal

17,440 GitHub stars and 142 contributors with commits landing as recently as April 2026 indicate the project is alive, not abandoned — which matters for a tool this old (tracing predates most of the current observability tooling wave). Latest release 3.6.1 suggests a mature, incrementally-versioned codebase rather than a project still finding its architecture. Apache-2.0 license means no restrictions on production use. CNCF maturity status is not publicly available in this profile, but Zipkin has long operated adjacent to CNCF projects (it predates OpenTelemetry and was a direct influence on it) rather than being a CNCF-hosted project itself — worth verifying independently before assuming graduated/incubating status.

Who should use this

Teams already running Java-heavy service stacks who want a lightweight, self-hostable tracing backend without committing to a heavier observability platform. Good fit if you want direct control over your trace storage backend (Cassandra/ES) and don't need built-in metrics/logs correlation out of the box. Also a reasonable choice if your instrumentation is already emitting Zipkin-format spans (B3 headers) and switching formats isn't worth the migration cost.

Who should NOT use this

  • Teams starting fresh today with no existing Zipkin instrumentation — OpenTelemetry is the de facto standard now, and building new tracing pipelines on Zipkin's native format instead of OTel is starting behind.
  • Anyone wanting a single pane of glass across traces, metrics, and logs — Zipkin only does traces; you'll need to bolt on Prometheus/Grafana/Loki or similar separately.
  • Organizations without spare ops capacity to run and scale a storage backend (Cassandra/ES) themselves — Zipkin gives you the tracing engine, not a managed service.
  • Teams needing enterprise support contracts, SLAs, or vendor accountability — there's no commercial entity standing behind Zipkin.

Alternatives

  • Jaeger — CNCF graduated project, OpenTelemetry-native, larger ecosystem momentum; the more common default choice for new tracing setups today.
  • Grafana Tempo — trace backend designed to integrate tightly with Grafana/Loki/Mimir if you're already in that stack and want unified observability.
  • Datadog APM / Honeycomb — commercial SaaS options if you want tracing without operating storage infrastructure yourself, at the cost of licensing fees.

Pricing

Fully open source, Apache-2.0. No paid tier, no enterprise edition. Your cost is entirely infrastructure and engineering time to run collectors, storage, and the UI yourself.

Frequently asked

What is Zipkin?+
Zipkin is a distributed tracing system. It collects timing data from services to help you figure out where latency is coming from in a request that hops across multiple processes — the classic "why is this call slow" problem in microservice architectures.
Who builds Zipkin?+
Zipkin originated at Twitter, modeled on Google's Dapper paper, to deal with debugging latency across Twitter's service graph as it decomposed its monolith. It's now maintained as an independent open-source project (openzipkin org) with 142 contributors and steady commit activity through 2026.
Is Zipkin production ready?+
17,440 GitHub stars and 142 contributors with commits landing as recently as April 2026 indicate the project is alive, not abandoned — which matters for a tool this old (tracing predates most of the current observability tooling wave). Latest release 3.6.
Who should use Zipkin?+
Teams already running Java-heavy service stacks who want a lightweight, self-hostable tracing backend without committing to a heavier observability platform. Good fit if you want direct control over your trace storage backend (Cassandra/ES) and don't need built-in metrics/logs correlation out of the box.
Who should not use Zipkin?+
Teams starting fresh today with no existing Zipkin instrumentation — OpenTelemetry is the de facto standard now, and building new tracing pipelines on Zipkin's native format instead of OTel is starting behind.
What are the alternatives to Zipkin?+
Jaeger — CNCF graduated project, OpenTelemetry-native, larger ecosystem momentum; the more common default choice for new tracing setups today. Grafana Tempo — trace backend designed to integrate tightly with Grafana/Loki/Mimir if you're already in that stack and want unified observability.
How much does Zipkin cost?+
Fully open source, Apache-2.0. No paid tier, no enterprise edition. Your cost is entirely infrastructure and engineering time to run collectors, storage, and the UI yourself.