Traces

Distributed traces, collected without code changes.

The time range

Shared across Traces, Metrics and Logs, so switching tabs keeps your window. Presets are 15m · 1h · 6h · 24h · 3d · 7d, or set an absolute range.

A preset is relative, so it re-resolves against the wall clock on its own — every 15s on the 15m window, up to every 5 minutes on 3d and 7d. You are not looking at a frozen snapshot.

Finding a trace

Three tools that compose into one query. Whatever you click in the sidebar is written into the same RQL the search bar uses, so you can start by clicking and finish by typing.

Facets

The sidebar filters by Duration, Status, Service, Span kind, and Tags.

Counts next to each value are computed with that dimension’s own selection excluded — so after picking serviceName: checkout, the service list still shows what the other services would return under your remaining filters. The counts stay useful instead of collapsing to your current selection.

• Status has three states: error only, non-error only, or both (no filter).
• Duration is a numeric range, translated to durationNano bounds.
• Tags filters on span attributes, one predicate per tag key.

RQL

RQL — the Runtimez Query Language — is what the trace search bar takes. Field predicates, directly:

serviceName : "checkout" AND hasError : "true"

Searchable fields:

Field	Notes
serviceName	Quoted string
name	The span name
env	Quoted string
hasError	"true" / "false"
statusCode	Numeric, unquoted
durationNano	Numeric, supports >= and <=
kind	Numeric OTel ordinal, unquoted
isRemote
traceID, spanID	Exact lookup
tags.<key>	Any span attribute
num.<key>	Numeric form of an attribute

Combine with AND / OR and parentheses. Multiple values on one field become an OR group:

(serviceName : "checkout" OR serviceName : "payments") AND durationNano >= 500000000

Two forms of the same tag

Span attributes are stored as strings, including numeric ones. A tag key is offered under the num. prefix only when every value seen for it parses as a number — otherwise num.k8s.namespace.name would be a predicate that can never match anything.

The results table

Column
Date	Span start
Trace ID / Span ID
Service
Span Name	The operation
Duration
Status
Method	HTTP method where present
Kind	Server, client, producer, consumer, internal

Reading a trace

Selecting a row opens the drawer: the waterfall, plus a DAG view when the call graph is more useful than the timeline.

The earliest span is not always the root

Queueing spans start before the span they belong to. The waterfall shows real parentage rather than ordering by start time — sorting by timestamp and calling the first row the root gives you the wrong answer on any request that waited in a queue.

Per-span tabs

Selecting a span in the waterfall gives you:

Tab	What it holds
Info	Attributes and span metadata
Errors	Exception type, message, stack
Infrastructure	The pod, node and container it ran on
Logs	Log lines correlated to this span
Metrics	Resource metrics over the span’s window
Queries	Database calls made inside the span
Runtime	Language-runtime detail

The drawer also carries a findings strip, neighbour strip for adjacent spans, a profile section where profiling data exists, and on-demand root-cause analysis and AI analysis of the trace.

Alternative views

Beyond the table, the same result set renders as Scatter (duration against time — outliers become obvious), Landscape, and Constellation views.

A worked search

Slow checkout requests in the last hour, excluding health checks:

1. Set the range to Last 1h.
2. Click checkout in the Service facet.
3. Drag the Duration facet above 500ms.
4. In the RQL bar, append AND NOT name : "GET /healthz".
5. Switch to Scatter to see whether it is a tail or a shift in the whole distribution.

From the CLI

rtz signals            # slowest operations by p99
rtz signals traces     # slowest individual traces
rtz trace list --since 2h --errors
rtz trace get <trace-id>   # the span tree, errors marked
rtz trace logs <trace-id>  # logs correlated to that trace

See Logs, traces & metrics.