Early access · Trace Analyzer is live

Backend diagnostics for teams running microservices

Paste a distributed trace. BackendBytes Diagnostics finds the critical path, the N+1 calls, the serial reads, and the errors your caller never saw — then ranks what to fix first.

Analyze a traceRequest early access

Runs in your browser · no account · nothing uploaded

A waterfall is not a diagnosis

Picture a checkout request that takes 1.26 s. No single span looks guilty: twelve 28 ms inventory lookups, a 140 ms pricing read, a 382 ms card authorization. Read as a waterfall, it is a wall of bars. Read as a critical path, about 30% of the time is one external call, roughly a quarter is a loop that should be one batched request, and a failing notification is swallowed, so it never shows up in the request error rate.

Finding that takes an engineer who knows what to look for, and time they rarely have during an incident. That analysis is what this project automates.

Real output on a synthetic checkout trace

20 spans · 8 services · 1.26 s

The three highest-ranked findings from the analyzer, run at build time on the sample trace. Synthetic data, not a customer system.

  1. Highup to 308 ms recoverable

    12× the same call under “checkout.PlaceOrder”

    Replace the loop with one batched call: an IN (…) query or join, a bulk endpoint, or a request-scoped batcher (DataLoader-style). If the data is reused within the request, cache it per request.

  2. Mediumup to 382 ms recoverable

    card-network · POST /v1/authorize owns 30% of the critical path

    Start here. For a database span, run EXPLAIN on the statement; for an external call, check its timeout, whether a hedged request or cache is acceptable, and whether it can leave the request path.

  3. Mediumup to 130 ms recoverable

    2 reads run back-to-back under “checkout.PlaceOrder”

    Check for data dependencies first. If the calls are independent, issue them concurrently — errgroup in Go, CompletableFuture.allOf in Java, Promise.all in Node — with a shared deadline.

Run it on your own trace →

What it does, and what is still being built

Each line carries its status. Nothing marked live is a demo.

  • Inspect traces and telemetry

    Turn an exported trace into a ranked list of what is making the request slow or wrong.

    • LiveOTLP/JSON and Jaeger trace import, entirely in the browser
    • LiveCritical path, self time, and per-service breakdown
    • LiveErrors that never reached the caller (swallowed failures)
    • PlannedCorrelating a trace with the metrics and logs around it

  • Analyze service architecture

    See the architecture a request actually exercised, not the one on the diagram.

    • LiveService-to-service call table derived from one trace
    • In developmentAggregating many traces into a dependency map with per-edge latency and error rate
    • PlannedFlagging chatty or deeply nested call chains across a sample of traces

  • Debug and optimize

    Every finding says what to try next. Explanations tied to your own code and stack are being built.

    • LivePer-finding recommendations: batch, parallelize, cache, instrument
    • In developmentClaude-assisted explanations that tie a finding to your stack and a candidate fix
    • PlannedCI check that compares exported traces between builds to catch latency regressions

How it works today

  1. 01

    Export a trace

    Download one from Jaeger, or read a line from the OpenTelemetry Collector's file exporter. Any OTLP/JSON works.

  2. 02

    Paste or drop it in

    The analyzer rebuilds the span tree, computes the critical path, and runs five deterministic checks. No account, no upload.

  3. 03

    Fix what is ranked first

    Each finding says what it saw, how much time is at stake, and what to try — with the caveat that a trace cannot see data dependencies.

Detection is code. Explanation is where Claude fits.

Findings come from tested algorithms, so they are reproducible and auditable: the thresholds are published on the tool page. The in-development layer uses the Claude API to explain a finding in terms of your stack and propose a candidate fix. The model is never asked to decide what is slow.

Built on a body of published work

BackendBytes started as an engineering publication. The platform inherits its standards: show the math, cite primary sources, say where the method is wrong.

Published engineering articles
63
Distributed systems, databases, Go, Java, and AI infrastructure. Browse
Interactive tools, each with its math shown
5
Capacity calculators and the Trace Analyzer. See all
Public editorial standards
Cited
Every claim traces to a primary source, checked at build time. Read the rules

Questions

Is my trace uploaded anywhere?
No. The Trace Analyzer parses and analyzes the trace in your browser tab. The page records that the tool was used and how many spans were analyzed, never the contents.
Which formats does it read?
OTLP/JSON, including the newline-delimited output of the OpenTelemetry Collector file exporter, and Jaeger JSON trace exports.
Is it free?
The Trace Analyzer is free to use today and needs no account. Hosted features, if and when they ship, have not been priced.
What is the status of the project?
Early access. One tool is live and unit-tested; the dependency map and the Claude-assisted explanations are in development; the rest is roadmap. The cards above mark which is which.
Are the findings generated by a language model?
No. Detection is deterministic code with tests, so the same trace always yields the same findings. The in-development explanation layer will use a model to explain a finding, not to decide what is slow.

Try it on a real trace, or tell us what to build next

We are looking for backend teams who will run it against real incidents and tell us where it is wrong.

Analyze a trace[email protected]

Also on GitHub and X.