Product Guides
Service Map
Use the service map to see call relationships, dependency direction, and the likely spread of a failure.
Overview
Use the Service Map to understand blast radius and direction. It is not just a diagram. It tells you who calls whom, which neighboring services may be involved, and whether a symptom is isolated or spreading through a request path.
Use this page after you know the approximate symptom and need to decide which evidence should come next. Keep the service, environment, and time range consistent as you move from summary pages to request-level detail.
How to read this page
Treat each edge as observed service communication for the selected filters. Follow direction before blaming the service where a symptom first appears. Change the time range when an expected dependency is missing or too sparse.
- Direction
- Caller and callee direction matters. A downstream service can make an upstream service look unhealthy.
- Edge evidence
- An edge means Vight observed communication in the selected filters. Missing edges usually mean no matching telemetry in that window.
- Blast radius
- Multiple unhealthy neighbors suggest a shared dependency, a caller pattern, or a release that affected more than one service.
Investigation workflow
Use this sequence when you need to move from a broad symptom to evidence you can share with another teammate.
- 1
Start with the unhealthy checkout service and inspect direct downstream calls.
- 2
If the payment service edge is slow or failing, open traces that include both services.
- 3
If several callers fail only when calling one dependency, inspect that dependency before changing the callers.
Interpretation note
Do not blame the node where the alert first appeared without following edge direction. Do not expect a dependency to appear if the selected time range has no matching traffic. Do not use the map as final proof. Open traces to confirm the actual request path.