Services
The two screens you'll spend most of your time on. The list answers "which service is unhappy?", the detail answers "why?".
The Services screen is your starting point — a sortable table of every service sending data, health at a glance, and a click-through into the detail of any one.
Services list — the entry point
Clicking Services in the left sidebar lands you here. The page is a sortable table with one row per service that has emitted data in the current time picker range.
Columns explained
- ServiceThe
service.nameresource attribute your apps send. Click it to open the service detail. - HealthA coloured pill: emerald / amber / rose / slate. Same colour meaning as the Home service grid.
- RPSRequests per second, averaged over the time window. Sparkline shows the shape over the window.
- Errors %Error rate as a percentage of requests. If a service has both a 4xx-heavy and a 5xx-heavy split, the cell colours just the 5xx contribution rose.
- p50 / p99Median and 99th-percentile latency in milliseconds. Cells turn rose if the value exceeds the per-service SLO target.
- SLO burnA pill showing the worst current burn rate, e.g.
14×for a "fast burn". Empty if no SLO is defined. - Deploys (24h)A count of deploys captured for this service in the last 24 h.
- Last seenRelative timestamp of the most recent span/log/metric. If a service has been silent for over 5 minutes, this cell turns amber — it might have stopped.
Controls above the table
- Search box — fuzzy match on service name.
- Health filter — show only emerald/amber/rose/slate rows.
- Group by — collapse rows by
environment(production/staging/dev) or byteamattribute (if your apps emit one). - Sort — every column header is sortable. Default is "worst health, then highest RPS".
Empty state
If no service has emitted data, the table is replaced with a card titled "Send your first signal" that links to Instrument your apps. If you expect services and don't see them, something is off in the ingestion pipeline — check the health strip on Home.
Service detail
Clicking a service opens the detail page. Its job is to answer "why is this service unhappy right now?" in a single scroll.
Layout, top to bottom
- ① HeaderService name, environment, the same coloured pill as the list, last-seen timestamp, two action buttons: "Define SLO" and "Create alert".
- ② KPI stripFour big tiles: RPS now, p99 now, error-rate %, error-budget remaining %. Each tile shows the current value, a sparkline, and the delta vs. the prior identical window ("vs. previous 1h").
- ③ The four chartsRPS over time, latency percentiles (p50/p95/p99 stacked), error rate, saturation (CPU/memory if reported). All four share the time picker.
- ④ Operations tableEvery endpoint this service exposes, ranked by traffic. Same column shape as the services list, scoped to one service.
- ⑤ Recent tracesA list of the 50 slowest traces touching this service in the window.
- ⑥ Recent logsA list of the 50 most recent error-level logs from this service in the window.
- ⑦ Recent deploysA vertical timeline of deploys for this service over the last 7 days.
- ⑧ TopologyA tiny service-map sub-view showing direct upstream and downstream services with edge thickness proportional to traffic between them.
② KPI strip — how to read it
Each tile has three numbers and a sparkline:
- Big number — the current value averaged over the last full bucket of the window.
- Delta pill under it —
+12%,-3 ms. Coloured rose if it's worse, emerald if it's better, slate if flat. "Worse" depends on the metric (latency worse = bigger; error budget worse = smaller). - Sparkline — the shape over the full window. Steeper end = recent change.
If a tile's value violates an SLO threshold, the tile gets a thin rose border and a SLO chip in its corner.
③ Four charts — what each shows and why
- Requests / sCounter rate. The shape tells you traffic patterns; sudden zero = the service died or its upstream did.
- Latency (p50 / p95 / p99)Stacked area. A growing gap between p50 and p99 means a slow tail — usually a slow downstream, a contended lock, or a stop-the-world GC.
- Error rate %Errors as a fraction of all requests. Two stacked layers: client errors (4xx, blue) and server errors (5xx, rose). 4xx growth often signals a bad client release; 5xx growth signals a bad server release.
- SaturationCPU and memory utilisation if the service reports them. Saturation that maxes out at exactly 100% is what causes the latency tail in the chart above.
All four charts honour the time picker. Drag-select any of them to zoom every other chart on the page.
④ Operations table — drill into a specific endpoint
One row per http.route (or per Kafka consumer group, or per gRPC method — whatever your SDK reports). Same columns as the services list but at the operation grain. Click a row to open the operation detail page which is the same shape, one level deeper.
⑤ Recent traces
Hover any row to preview the waterfall in a tooltip. Click to open the trace detail drawer. Traces here are pre-filtered to the slowest 50; toggle "errors only" to switch to error-only.
⑥ Recent logs
Each row: timestamp · severity · message · attributes peek. Click to open the log detail drawer with the full record, JSON view, and a "See in logs" button that opens the Logs screen pre-filtered to this service and message template.
⑦ Recent deploys
A vertical list with one chip per deploy: commit · author · timestamp · "rolled back" if applicable. If an error spike in chart ③ coincides with a deploy, the chip glows.
⑧ Topology mini-view
Shows two columns — direct upstreams on the left, direct downstreams on the right. Edge thickness = traffic. Edge colour rose if that edge has error spikes. Click any node to navigate to its service detail. To see the full graph, jump to Service map.
What this screen is not
This screen does not show every trace or every log — just the slowest and most recent. For exhaustive query, go to Explore → Logs or Explore → Traces. The buttons "Open in logs" and "Open in traces" at the top of the page take you there with the filter pre-applied.
Next: Service map.