Errors, logs and services

After this page you can start from a spike of identical errors, a log line or a slow service and end on the single trace — and the span inside it — that explains it, with an alert one click away.

Errors

Traces → Errors groups error spans by service, span type and message, so one bad deploy reads as one row rather than hundreds. The header counts error events, distinct errors and services affected. Each group shows message · service · span type · count · trend against the previous window (an arrow and sparkline) · last seen; sort by count or trend. Expanding a group shows the full message and stack, first and last seen, affected models, and three exits: Open the sample trace (lands on the failing span), See all traces in this group (the list filtered to status ERROR and the message) and Create alert for this error, which prefills an alert rule. On the sample trace the waterfall highlights the failing span, and Optimize turns the finding into a fix prompt — see The trace page.

Logs

Traces → Logs searches the log spans of the Environment: a search box, level chips (DEBUG · INFO · WARN · ERROR · CRITICAL), the time range, a live tail, and a row limit of 500, 5k or 50k that is part of the query — the footer says when the answer was capped. Lines show time · level · service · message and a trace badge. “No log lines in this range” is a different state from an Environment that has never sent logs. Clicking a line opens its trace on the Logs tab with the line focused; Jump to the span that logged it highlights the span. The SDK captures the standard logging module in Python and console.* in TypeScript; each line is a log span, which is why every line already belongs to a trace.

Services

Traces → Services rolls the Environment up by service_name over the shared time range (15 m to 30 d, custom, and compare to previous period). The stats row shows requests — root spans, one per trace, the same population as the trace list — error %, and p50 · p95 · p99 request latency, each with a sparkline and, when comparing, a ▲/▼ delta. Below it a RED chart (requests and errors as bars, p50 and p95 as lines; drag to zoom, double-click to reset, click a bucket to open its traces), a service map (node size is volume, edge width is calls, colour is the error share; click a node to narrow the table to it and its neighbours) and the services table: service · requests · rate · error % · p95 · ≈cost / request (blank for a service that made no model calls) · last seen · trend, searchable and sortable. A service page repeats the RED tiles and chart for one service, adds its latency distribution with p50 · p75 · p95 · p99 markers, an operations table — the root-span operations, which is why they read like routes — with a trend per row, Inbound and Outbound tables from the map, and a Recent errors panel that opens Error groups or error traces. An endpoint page scopes the same chart and distribution to the exact operation and offers example traces — fastest (≤ p50), typical (≤ p95), slowest (≥ p95), errors — each naming its filter; clicking a distribution bucket adds its lower edge to every link. Every link carries the range. Below two buckets of data a chart says *not enough data*; the figures still show.