Query builder for spans

The Spans and Traces tabs of Explore spans extend the standard Coralogix query builder with three controls tailored to span data: error filters, duration filters, and span-relationship filters. All three apply to the active tab and stay in sync with your search, Group by, and aggregation choices.

Toggling the Errors filter or selecting Apply on Duration runs the query automatically—the results table and the count chart above it update in place.

For the shared building blocks—search bar, Lucene and DataPrime modes, Group by, Aggregation, and drilling down into grouped results—see the main Query builder doc.

Filter by error

Use the Errors toggle to narrow results to spans or traces that include an error.

• In the Spans tab, the toggle shows only spans whose status indicates an error.
• In the Traces tab, it shows traces that contain at least one error span.

Combine the error toggle with a service or operation filter to jump straight to failing executions without rewriting your query.

Filter by duration

Use the Duration control to isolate slow operations.

• In the Spans tab, filter by span duration. Trace duration is not currently supported.
• Enter a minimum and maximum in milliseconds, or choose a percentile (p25, p50, p75, p95, p99). For example, p95 shows only spans slower than 95% of all spans in the current result set.
• Select Apply to execute the filter—this triggers an automatic query run.

The duration filter applies to the active tab and updates the results table and the count chart above it simultaneously.

Filter by span relationships

Use relational filters to find spans based on their position within a trace. Relational filters are available in all tabs of the spans dataset when the Monitoring, Archived, or S3 data tier is selected. You can add multiple relation filters at once and combine them with AND or OR — except for Only root, which can be added once because it restricts the entire result set and applying it more than once would have no additional effect.

1. Go to Relation, then select Add relation filter.
2. Choose a relation type.
3. In Field, pick a span attribute or tag — for example, service.name or http.status_code.
4. Choose an operator — Equals (default) or Not equals.
5. Select one or more values.
6. Select Run to apply the filter.

The builder generates the matching DataPrime relational query automatically. Switch to DataPrime at any time to inspect or edit the generated syntax — start with the visual builder and switch to DataPrime when you need more precise control, without losing your work.

Examples

End-to-end queries that combine the controls above with the shared builder primitives.

Find slow database spans:

1. Tab: Spans.
2. Search: db.system:*.
3. Duration: 500ms – ∞, or p95.
4. Group by: db.operation.
5. Aggregation: count.

Result: a grouped list of DB operations with counts, sorted by frequency—helping you identify which query type is slowest.

Find error spans in the checkout service:

1. Tab: Spans.
2. Search: coralogix.metadata.serviceName:"checkout-service".
3. Errors toggle: on.

Result: every error span produced by the checkout service in the active time range.

Find the slowest checkout requests that errored:

1. Tab: Spans.
2. Search: coralogix.metadata.serviceName:"checkout-service".
3. Errors toggle: on.
4. Duration: > p95.

Result: the slowest 5% of error spans in the checkout service—useful for tail-latency error investigation.

Find traces that errored in the checkout service (with the Any relation):

1. Tab: Traces.
2. Errors toggle: on.
3. Any relation filter: service.name = checkout-service.

Result: all traces that contain at least one error span in the checkout service.

Isolate every root span regardless of service (with the Only root relation):

1. Tab: Spans.
2. Only root relation filter (no field or value condition needed).

Result: only the entry-point spans for each trace, with all child spans removed from the view.

DataPrime equivalent for the slow database spans example:

source spans
| filter db.system != null
| filter $m.duration > 500000000
| groupby db.operation
| aggregate count() as span_count

Span events

Span events — exceptions, logs attached to a span, or other structured events recorded during instrumentation to capture what happened at a specific point in a span's execution — are queryable through DataPrime when you need to filter or aggregate across them, and surface in the trace view for at-a-glance inspection. This is especially useful when investigating recurring exceptions or errors across many spans at once.

Query events with DataPrime

Span events live as a logs array on each span and aren't exposed in the Query builder controls. To filter, count, or aggregate spans by an event-level attribute — for example, exception.type or exception.message — open Explore, switch the search bar from Builder to DataPrime mode, and use explode to flatten $d.logs into one row per event.

How explode works

The explode command expands an array field into individual rows so each element can be queried separately. Applied to span events, it takes the logs array on a span and creates a new row per event, letting you filter, count, and aggregate on event-level fields like exception.type and exception.message.

Explore query bar in DataPrime mode, running an explode $d.logs query against the spans dataset.

Use this pattern when you want to:

• Count or rank events by an event-level attribute (for example, the most common exception types across spans).
• Filter spans whose events match a condition while preserving the original span fields.
• Find every span that contains a specific event type — for example, every span that recorded an exception.

Count exceptions by type:

source spans
| explode $d.logs into $d.exploded
| countby $d.exploded.fields['exception.type']

The result is a count of span events grouped by exception.type — useful for quickly identifying the most common errors across your spans.

Find spans whose events include a specific exception type:

source spans
| explode $d.logs into $d.exploded original preserve
| filter $d.exploded.fields['exception.type'] == 'GraphQLError'
| remove exploded

original preserve keeps the original span fields on each new row, so the result returns the spans (not just the events) that contain a matching event. remove exploded drops the per-event payload before the spans are returned. Use this when you want to identify which spans — not which events — are affected by a specific exception type.

View events in the Gantt, Info panel, and Related data

• Gantt view: spans that carry events show a small marker on the right edge of their bar, visible without selecting the span. Use this to quickly identify which spans recorded exceptions or events without opening each one individually. See Visualize spans and traces.
• Info panel: selecting a span opens the Events section in the Info panel, with each event listed by timestamp. Expand an entry to see its attributes — for example, event, level, code.filepath, code.lineno, code.namespace, and any custom fields attached to that event. See Span fields and attributes.
• Related data: the Events tab in the Related data drawer surfaces the same per-span events when you open the drilldown from the Gantt or results table. See Span related data.

Gantt span bar with the event marker visible, the Info panel Events section with an expanded entry, and Events in the Related data drawer.

Next steps

Investigate a span or trace in depth in Span drilldown.