Find what’s slowing down your application.
Follow a request across your services and see the operation that took the time. A trace shows which call waited, on what, and for how long — your own code or something downstream.
- +1.20spool wait above 1s
- +1.90sacquire timeout · TimeoutError
Narrow a slow endpoint to one span
A trace turns “checkout is slow” into the operation responsible for it. Here is one endpoint, from the latency alert to the span that explains it.
Follow requests across your services
Distributed tracing over OTLP, with the search, comparison and sampling controls that keep it usable at volume.
Every span with its own timing, attributes, events and errors, across services, in one view.
waterfallFilter by duration, status, service, route, span attribute or error to find the requests you want.
trace-searchStatement shape, row counts and time in the driver, without the statement text leaving your systems.
db-spansWhich service calls which, at what rate and with what error share, drawn from the traces themselves.
service-mapThe same endpoint at the same percentile, before and after a deploy, side by side.
compareKeep errors and slow requests in full and thin the routine successful ones.
samplingWhen a span is using CPU rather than waiting, open the profile covering the same period.
profilesSee which endpoints cost the most.
The same trace data answers a slower question week to week: where your latency budget is going, and which endpoint is worth the time to fix.
- Ranked by impact. Request rate times duration, so a slow endpoint nobody calls ranks low.
- p50, p95 and p99 together. A p99 that moved alone points somewhere different from a p50 that moved.
- Error share alongside. See whether a slow endpoint is also failing.
- Open a real example. From any cell to an actual trace at that percentile, not an average.
Start tracing your services.
Send OTLP from the instrumentation you already have and see your first trace waterfall in minutes. Start on the free plan with no card.