Service dependency map
A live graph built from traffic or traces that shows which services call each other and where failures or latency travel.
See it
What it is
A service dependency map is an automatically generated graph where services are nodes and observed calls are edges. Trace backends such as Grafana Tempo can derive the graph from client and server spans, then decorate each edge with request rate, errors, and latency. Datadog and New Relic ship the same picture under the name service map.
Reach for it during an incident when you need to see which upstream service depends on the failing one, or when the real production topology has drifted away from the architecture diagram. It is also a quick way to spot an unexpected cross-service call.
Gotcha: this is a map of observed traffic, not declared architecture. Unsampled traffic, broken trace propagation, idle services, background jobs, and messaging systems can leave real edges missing. Treat an absent edge as 'not seen in this window', not proof that no dependency exists.
Ask AI for it
Build a service dependency map from OpenTelemetry traces. Set a stable service.name on every service, propagate W3C Trace Context across HTTP and queue boundaries, and emit paired client and server spans with server.address, http.request.method for HTTP calls, rpc.system for RPC calls, and error status. Enable Grafana Tempo's service-graphs metrics-generator processor, remote-write the generated series to Prometheus, and add a Grafana node graph showing request rate, error rate, and latency on each edge. Add an integration trace that proves one known call appears in the map.