Errors, logs and services

These views start from a pattern across many traces, such as a spike of identical errors, and end on the traces that explain it.

Errors

Traces → Errors groups error spans by message, service and span type, so one bad deploy reads as one row. Tiles count error spans, distinct errors and the services affected.

Each row shows the message, service, span type, count, a sparkline with the change, and last seen. Sort by volume, trend (the newer half of the window against the older half) or last seen.

Click a row to open the group, with its occurrences, share, first and last seen, and a chart. From there:

• Open the sample trace opens one trace with the failing span selected.
• See all traces in this group opens the list filtered to status:ERROR, the service and the message.
• Create alert opens the alert rules with nothing filled in. See Alerts.

On the sample trace, Optimize turns the failure into a revised system prompt and a fix prompt. See The trace page.

Logs

Traces → Logs searches the log lines of the Environment by text, level, service and time range. Live tail refreshes every 5 seconds.

Lines load 500 at a time, with Load more. Each shows its time, level, service and message, and a link to its trace that keeps the range. Expand a line for its trace, span, operation and attributes. An empty window says "No log lines in this window", and a search with no match says "No log lines match".

The SDK captures Python logging and TypeScript console.* calls as log spans, which is why every line already belongs to a trace. From SDK 0.3.6, Python records WARNING and up by default, and TypeScript no longer records a console.log outside a span as a span of its own; Logs and console output says how to record more.

Services

Traces → Services rolls the Environment up by service_name over the shared time range, with Compare to previous period. A request is a root span, one per trace, the same population as the trace list.

Tiles show requests, error %, and p50, p95 and p99 latency, each with a sparkline, and the change when comparing. The chart draws requests and errors as bars and p50 and p95 as lines. Drag to zoom, double-click to reset, and click a bucket to open its traces.

In the service map, node size is volume, edge width is calls and color is the error share. Click a node to narrow the table to it and its neighbors.

The services table lists requests, rate, error %, p95, ≈cost per request, last seen and trend, and can be searched and sorted. Cost is blank for a service with no model calls.

A service page repeats the tiles and chart for one service and adds its latency distribution with p50, p75, p95 and p99 markers. Its operations table lists root-span operations, which is why they read like routes. From SDK 0.3.3 a request span is named by the route the framework matched, such as GET /orders/{order_id} (FastAPI, Starlette, Flask and Django in Python; Express, NestJS and Fastify in TypeScript), so all orders are one operation; a request that matched no route keeps its path. Earlier SDKs named it by the path, one operation per id. Inbound and Outbound tables come from the map, and Recent errors opens error groups or error traces.

An endpoint page scopes the chart and distribution to one exact operation and links example traces: fastest (≤ p50), typical (≤ p95), slowest (≥ p95) and errors. Clicking a distribution bucket sets every example link to traces at or above its lower edge. Every link carries the range. With fewer than two buckets of data, a chart says "Not enough data"; the figures still show.