End-to-end request tracing
Follow a single request from the edge through every microservice, database call, and external API — every hop is captured as a named span.
Distributed Tracing
Follow every request
Follow every request
across every service.
Spans, a latency waterfall, and automatic service maps — find the slow service in a single request that touched a dozen, then jump straight to the related logs and metrics without switching tools.
Free tier included
No credit card
2-minute setup
POST /checkout · trace HealthyLIVE
TOTAL DURATION842ms
SPANS14
SERVICES5
api-gateway38ms
auth-service62ms
inventory-svc94ms
payment-service580ms
notification-svc42ms
What you get
One trace, the whole story.
A single slow request can touch a dozen services before it returns. Distributed tracing follows every hop, records every span, and renders the complete latency waterfall — so you know which service added 580ms and exactly why.
Latency waterfall view
The waterfall timeline shows every span in order, with start time and duration drawn to scale so the critical path is immediately visible.
Automatic service maps
Service dependency graphs are inferred from trace data — no configuration required. See which services call which and where errors propagate.
Trace search and filtering
Search by service, operation name, duration range, status code, or any span attribute to find the exact request across thousands of traces.
OpenTelemetry native
Accepts traces over OTLP/HTTP and OTLP/gRPC — any OTel-instrumented application can point its exporter at Site Qwality with no SDK changes.
Correlate with logs and metrics
Jump from a slow span directly to the log lines emitted during that exact time window and service, without leaving the trace view.
01 · Find the bottleneck
Stop guessing which service
Stop guessing which service
is the slow one.
The latency waterfall makes it obvious. Each span shows its own contribution to total request time — scroll to the widest bar and that's your bottleneck. Drill into the span for full attributes, events, and any child spans it spawned.
- Critical path highlighted — sequential bottlenecks are easy to spot
- Span attributes expose DB query text, HTTP target, and custom metadata
- P50 / P95 / P99 per operation across all sampled traces
GET /product/:id · trace HealthyLIVE
TOTAL DURATION394ms
SPANS8
P95 · OP320ms
router12ms
auth-middleware18ms
product-svc24ms
cache-check9ms
db-query320ms
02 · OTel in minutes
Already instrumented?
Already instrumented?
You're already done.
Site Qwality speaks OTLP natively. If your services already export OpenTelemetry traces — with the OTel SDK, auto-instrumentation, or an agent — change one environment variable and traces start arriving. No proprietary SDK, no vendor lock-in.
- OTLP/HTTP and OTLP/gRPC both supported
- Works with every OTel SDK: Go, Java, Python, Node.js, .NET, Ruby
- Bring your existing instrumentation — no code changes needed
configure OTLP exporter# Set in your service environment
OTEL_EXPORTER_OTLP_ENDPOINT=https://traces.siteqwality.com
OTEL_EXPORTER_OTLP_HEADERS="x-sq-key=YOUR_API_KEY"
OTEL_SERVICE_NAME=payment-service
OTEL_TRACES_EXPORTER=otlp
# Restart your service — traces appear immediately
OTEL_EXPORTER_OTLP_ENDPOINT=https://traces.siteqwality.com
OTEL_EXPORTER_OTLP_HEADERS="x-sq-key=YOUR_API_KEY"
OTEL_SERVICE_NAME=payment-service
OTEL_TRACES_EXPORTER=otlp
# Restart your service — traces appear immediately
14
spans captured per typical checkout request
<1s
trace search latency across millions of spans
0
proprietary agents — standard OTLP only
$0
free tier — start without a credit card
FAQ
Questions, answered.
Point your OpenTelemetry exporter at your Site Qwality ingest endpoint using OTLP/HTTP or OTLP/gRPC. Set the API key header, restart your service, and traces arrive immediately. No proprietary SDK required.
Any service instrumented with the OpenTelemetry SDK is supported — Go, Java, Python, Node.js, .NET, Ruby, PHP, and more. Auto-instrumentation libraries handle most frameworks without code changes.
Yes. When your application emits logs that include the trace ID — standard with most OTel logging integrations — the trace view shows a direct link to the correlated log lines for each span.
The service dependency graph is automatically derived from span parent-child relationships in your trace data. No manual topology definition is required — it reflects your actual traffic patterns.
Trace retention is configurable per plan, typically 30 days for detailed span data. High-volume environments can use head-based or tail-based sampling to control storage while preserving the traces that matter most.
More of the platform
Explore the rest of the platform
Ready?
Start watching in under a minute.
Every product starts free — uptime, cron, synthetic, logs, RUM, incidents, and status pages. No credit card required.