Start with what is wrong
The tiles at the top name up to two services in each unhealthy state. Below them the list is sorted worst first, and you can filter by status.
Platform
See which services are in trouble before you open a trace.
Services lists every service that sent traces, logs or metrics in the time range you picked, with its status, request volume, failed share and p95 latency. The ones that need attention come first.
What you get
Go from a status to a reason
Open a service and a drawer shows its errors, its slowest operations, its dependencies and its instances, with buttons to the matching traces and logs.
Honest about thin data
A service with too few requests shows Not enough traffic. A service that sent no requests shows No requests. Neither is dressed up as healthy.
How it works
Services appear on their own
Any service that sends telemetry with a service name shows up. Nothing to register.
Requests are counted once
A request is an entry span: a server span, a consumer span or a root span, with health probes left out. A failed request is a trace with an error span in that service.
One rule for every workspace
The status rule is fixed. It is not configurable per workspace, so two teams reading the same number are reading the same rule.
Service Catalog adds ownership
- Five checks per service. An owner is recorded, it is reporting telemetry, an alert rule covers it, it has an SLO, and it has no open incidents.
- A count, not a percentage. Each service shows how many of the five it passes, and the list starts with the lowest scores.
- Owners are yours to set. Admins record who owns a service. The record is audited.
Find the service that is struggling.
Send a few services and the list builds itself.