Zipkin collects and displays distributed traces: how many services a request passed through, where it spent the most time, and which hop threw the error. With a single app, logs are enough; the moment two apps call each other, "where is it slow" stops being answerable by reading each side’s log.
What you would use it for
Find the slow hop in a call chain across several services, instead of guessing by comparing timestamps between log files.
Stand up a trial environment for an application that already ships tracing libraries, without preparing any storage first.
Learn or demonstrate distributed tracing: post a few traces by hand to port 9411 and watch them appear on the dependency graph.
What Keenrig handles for you
Wants 512 MB of memory — the heaviest entry in the current catalogue, because traces live in process memory.
Health checked at its own `/health` path, so the platform never mistakes a slow-loading UI for a dead app.
Pinned by digest `sha256:d17e856d…` rather than by the `3` tag: a redeploy next month runs exactly today’s image.
What it does not do. The default configuration keeps traces IN MEMORY. Redeploy, restart, or replace the container and every previous trace is gone — a deliberate choice so this entry needs no disk, not an oversight. If you need traces to survive for days, Zipkin requires external storage (Cassandra, Elasticsearch, MySQL), and this catalogue entry does not set that up for you.
Add an install button to your README
Maintain Zipkin? Paste this into your README so readers can install it with Keenrig:
[](https://keenrig.com/en/apps/zipkin)