# Dependencies and waits

A dependency is something your service calls while doing its work, such as another service, a database or an external API. Service Health shows those relationships so you can investigate where slowness or failures may start.

## The dependency view

Open **Health → Dependencies**. The view compares the last seven days with the seven before. A focused service sits between its callers and what it calls. Select a service to move the focus, and use the trail to return.

Links describe measured calls between systems. They are not a complete architecture inventory: missing instrumentation or traffic can mean a relationship is absent.

## What makes a link troubled?

These link states compare dependency measurements with their previous period. They are separate from an API's SLO budget:

| Link state | Failure change | Latency change |
| --- | --- | --- |
| Breached | More than 1% of calls fail, and the rate is at least twice the previous period | p95 is at least twice the previous period |
| At risk | More than 0.5% fail, and the rate is at least 1.5 times the previous period | p95 is at least 1.4 times the previous period |

Either the failure condition or the latency condition can flag the link. A link becoming slower does not by itself mean an API has exhausted its error budget.

When no previous failure rate is available, the current failure threshold alone can flag a link. Latency needs a positive previous duration for a comparison, so no previous duration means no latency-change judgement.

## Likely causes and affected services

The app follows troubled relationships to suggest where to start. A service others wait on may be shown as a root cause when nothing it calls explains the trouble. Services waiting on it are affected.

Treat this as an investigation lead. The map can show the observed chain, but it cannot prove that fixing one node will solve the incident. Check source traces, timing and changes before assigning a cause.

For example, Checkout may slow down while waiting for Pricing, and Pricing may be waiting for a database. Investigating only Checkout's code would miss the next part of that chain.

## What it waits on

Inside a service or API, **What it waits on** opens a map of the calls and the next hop beyond them. Switch to the list to read the measurements and API pairs. Open an owned API to inspect it, or follow an external system on the dependency map.

| Figure | How to read it |
| --- | --- |
| Calls per request | How often the API calls that dependency for each request it handles |
| p95 | The duration of most dependency calls, with a comparison when available |
| Failed | The share of dependency calls reported as failed |
| Change | How latency or failure differs from the previous week |
| Where its time goes | The measured split between its own work and dependency waits, where available |

A dependency called several times per request may be worth attention even when each call is fairly quick. The split is a diagnostic view of measured timing; it does not establish how long the customer waited in their browser.

Calls can run in parallel, so their combined durations can exceed the request's duration. When that happens, the bar shows shares of total waiting and no remaining own-work portion. Background work can also appear separately. Read the bar as a breakdown of measured time, rather than a sequence of steps that happened one after another.

## An investigation to try

1. Start with the suggested cause and read the numbers behind it.
2. Follow the call path to see which APIs are involved.
3. Check whether slowness, failures or more calls per request explain the change.
4. Compare the relevant time with a release or source trace.
5. Agree an action with the owning team, then check both the dependency measurements and the affected API's budget.

## Learn more

- [Reading the health screens](/docs/service-health/reading-health)
- [Google SRE book: Effective troubleshooting](https://sre.google/sre-book/effective-troubleshooting/)