Service Health
Reading the health screens
The health screens take you from services needing attention to the API and day behind a problem. This guide explains how to read them without confusing a recent slowdown, an objective breach and missing data.
Services
Open Health → Services and select your team. Start with services marked Breached or At risk, then open one to investigate.
A service's headline status reflects trouble in its counted APIs. Its whole-service budget answers a different question: how much of the allowance all eligible calls have spent together. A quiet API can be breached even when the service-wide budget has plenty left.
Check the data timestamp too. A status based on the last successful pull can remain visible after measurements stop arriving.
Problem APIs
Health → Problem APIs brings APIs needing attention into one list. Each belongs to a service and inherits its objectives unless someone has made an exception. Open an API to read its speed and success objectives separately.
| Reading | What to ask |
|---|---|
| Breached | Which allowance is used up, and is the problem still happening? |
| At risk | How much remains, and how fast is it being spent? |
| Healthy | Is it steady, or worsening while still inside its allowance? |
| No data or not known | Are there enough calls and usable measurements to judge it? |
| Not held to speed | Is it stream or background work, where duration is not a request-speed measure? |
An API needs at least 100 calls over its objective window for a judgement. Calls without a named route are counted separately, and excluded APIs do not participate. See Endpoints and exclusions.
Inside a service
The headline figures open details below them:
- Speed budget: the service's allowance for slow calls, with its budget line and burn spikes.
- Error budget: its allowance for server errors.
- Now vs before: whether speed improved or worsened across two 28-day periods.
- Who spent it: the APIs contributing to the service's speed-budget spending.
- What it waits on: the calls to other services and external systems behind its response time.
Use the budget guide for the arithmetic and the dependency guide for following waits.
Inside an API
Read Objectives first. Speed and success show their targets, where those targets came from, the permitted bad-call share and the actual share. An API override includes its reason.
Then follow the budget line to a day where spending increased. Open that day to see p95 and p99 every five minutes, when retained. The detail also looks for p95 staying above the slow line for 30 minutes; this helps locate a sustained slowdown, but does not determine the SLO itself.
Sample requests shows examples of the source request names grouped into the API. These are name samples with counts, rather than individual request records. Use them to check whether endpoint templating grouped the right names.
Now vs before
The solid line shows the last 28 days' daily share of calls meeting the speed threshold. The dashed comparison shows the previous 28 days, aligned day by day. The objective line gives the target.
The summary compares each period's share weighted by call count. A day with 10,000 calls contributes more than a day with ten. A move from 99.5% to 99.0% is a decrease of 0.5 percentage points, not a 0.5% error rate.
A falling trend can be worth investigating even while the objective is healthy. Unknown threshold counts remain missing rather than being shown as zero slow calls.
Filters and windows
Team filters scope what you can see. The activity range changes traffic and latency readings, while objective status still uses the tier's configured rolling window. Now vs before uses its two 28-day periods, and dependencies compare the last seven days with the seven before.
Read the period beside each figure. A seven-day activity view does not turn a 28-day objective into a seven-day one.
When a number is missing
Missing detail can mean no calls, too few calls, a measure the source has not supplied, or five-minute points that were not retained. It is not the same as zero errors. Check Admin → Setup and Admin → Connector, or ask your admin, before changing the target.
How this fits wider monitoring
Google's Monitoring distributed systems describes four golden signals: latency, traffic, errors and saturation. Saturation is how close a resource is to its capacity. Service Health's request counts, durations and server errors help you understand the first three; use your resource monitoring to investigate capacity as well.
A service can return successful HTTP responses while producing the wrong result. These objectives measure the recorded speed and server-error behaviour, so combine them with checks of the customer journey and correctness where those matter.