Tracing
Follow one request through every service it touched.
A checkout touches the gateway, auth, inventory, payments, a database and an event bus — in 400 milliseconds. TraceLoop captures the whole journey, keeps every trace that matters via tail-based sampling, and puts the waterfall one click from the logs and the incident.
Trace Explorer
One request, nine spans, one deadlock
Fictional trace 7c1f9a2b: a checkout that hit a Postgres deadlock, retried transparently and still completed in 412ms. The red span is where the investigation starts — and ends.
trace waterfall
trace_id=7c1f9a2b · POST /v1/checkout · 412ms · 9 spans
POST /v1/checkout
edge-lb
route.request
api-gateway
verify_token
auth-svc
create_order
checkout-svc
hold_inventory
checkout-svc
INSERT orders
postgres-01
INSERT orders (retry)
postgres-01
capture_payment
payments-svc
publish order.created
kafka-events
span detail
INSERT orders · postgres-01 · span 6 of 9
db.system postgresql
db.statement INSERT INTO orders (id, user_id, total) VALUES ($1,$2,$3)
error.type deadlock_detected (40P01)
retry attempt 2 succeeded · +33ms
deploy checkout-svc v2.41.3 · 11 min before incident
Tail-Based Sampling
Keep every trace you'd want at 3am
Head sampling gambles that the interesting decision was made before the request started. Tail-based sampling waits until the trace completes, then applies policy — errors and anomalies are never dropped.
- Policy engine evaluates the full trace, not just the root span
- Storage typically drops 40–70% versus keep-everything, with zero investigative loss
- Worked example: 900k spans/sec reduced to 240k retained — every error kept
sampling policies
evaluated at trace completion · order matters
- 100%
status = ERROR
all failed traces, forever searchable
- 100%
duration > 2 × p95
tail latency always preserved
- 100%
anomaly_score > 0.7
detector-linked traces captured
- 25%
route = /v1/checkout
critical path over-sampled
- 2.5%
healthy baseline traffic
statistically representative sample
service map
inferred from live traffic · edge latency & error rates
Service Maps
The topology you think you have, versus the real one
TraceLoop draws the dependency graph from observed traffic — including the shadow dependency nobody remembered. Per-edge latency and error rates make the weak link obvious.
- Auto-refreshed every 60 seconds from live spans
- Degraded edges highlighted with the driving span kind (DB, cache, queue, RPC)
- Click any edge to see its slowest traces from the last hour
Capabilities
Tracing that respects your stack and your budget
Tail-based sampling
Decisions happen after the trace completes: keep 100% of errors, slow spans and anomalies, sample healthy baseline traffic to 2.5%. Every interesting trace survives.
Waterfall & flamegraph views
Span waterfalls with inline logs and DB statements, flamegraphs for hot-path analysis, and span-level compare against the 7-day baseline.
Live service maps
Dependency topology inferred from real traffic, with per-edge latency and error rates. Spot the degraded dependency before your users name it.
OpenTelemetry native
OTLP in, OTLP out. W3C trace context and baggage propagated end-to-end. Bring any OTel SDK — or use our zero-code auto-instrumentation agents.
Every interesting trace, kept. Every boring one, cheap.
Tail-based sampling, live service maps and OTel-native ingest — see it on your own services this week.