Service Map
The Service Map is the Datadog APM view that automatically draws the call relationships between services from collected traces, showing the whole picture of dependencies and where things get stuck in a single diagram. Nodes represent services, lines represent aggregated calls, and the color of a node's border tells you the health of that service.
Overview
The Service Map is a diagram that lays out the services collecting traces in APM as components and connects them with lines showing the direction of observed calls. If you have APM or RUM in place, no extra configuration is needed: instrumented services and their connections appear right away, and they disappear automatically when no matching trace arrives for 30 days. A separate map is drawn per env, and you can narrow it down by facet or service name. You care about it when requests are slow but you cannot pin down which service is responsible, when you want to check whether unknown external calls or services have crept in, and when you want to confirm who owns a service and where team boundaries lie. How a trace is stitched together is left to the Distributed Tracing entry; this entry focuses on how to read the view.
A view that draws dependencies from traces
The Service Map is a view that takes the traces collected by APM as its raw material, breaks your application into components called services, and draws the observed dependencies in real time. The official documentation describes it as a view for identifying bottlenecks and understanding how data flows through your architecture (as of September 2026, Source: Service Map). The raw material is APM and RUM data, and if you have those in place the map displays with no additional configuration. The value of this view is that the diagram is born from requests that actually flowed, rather than from an architecture diagram that someone draws and maintains. A call that is missing from the design document still becomes a line if it is flowing. How a request that crosses services is stitched into a single trace is left to the Distributed Tracing entry; here we focus on how to read the diagram that gets drawn.
One node is one service, one line is an aggregate of calls
Each element of the diagram has a fixed meaning. A node is a service exactly as instrumented in APM, and matches the services listed in Software Catalog. A line is an aggregate of the calls from one service to another, the accumulation of the calls that show up in the flame graph of individual traces.
| Element | What it represents | Notes |
|---|---|---|
| Node | One service instrumented in APM | Only services with data in the selected time range are drawn |
| Line (edge) | Aggregate of calls between services | Hovering shows the direction as an animated line |
| Border color (red / yellow) | The Service Health of that service | Watchdog anomalies, monitors that page people, and incidents rolled up into one status |
| Collapsed node | An intermediate service hidden by filtering | Appears when two filtered services are connected through a service outside the filter |
| Time until removal | 30 days | When no matching trace arrives for 30 days, the service and its lines disappear automatically |
The only color meanings the official documentation lists are the two border colors, red and yellow, driven by Service Health. Whether latency or error rate is high or low is not shown in the look of the diagram; you confirm it on the service page opened from the node. Only services with data in the selected time range appear on the map, so a service that runs only for a limited window, such as a nightly batch, does not appear until you widen the range.
Filtering and switching scope are different operations
There are two operations that look similar but differ. One is filtering, done by fuzzy matching on the service name or by the facets Datadog attaches to services automatically. The facets include the type of service, such as web server, database, or cache, the time of the most recent deployment, and monitor status (as of September 2026, Source: Service Map). The other is switching scope: the map is drawn per env and, optionally, per a second primary tag you configure. Selecting a different env switches to a separate map made up of only the services in that scope, and no lines are drawn for calls that cross envs. When you change the scope and an unfamiliar service appears, first confirm which of these two operations you are using. You can also group by team or application, and the official documentation lists confirming service ownership on the map as a use case.
Read left to right - from the user side toward the root cause
Hovering over a node shows the flow of that service's requests as animated lines, so you can see which side is calling which. Clicking to inspect isolates that service, with its callers lined up on the left and the services it calls on the right. The official documentation explains that services further to the left are closer to the user, and services further to the right are more likely to be the root cause (as of September 2026, Source: Service Map). How to read the map during an incident comes down to that one sentence. Even when the entry service closest to the user is red, the cause is often on the right, so follow the red borders to the right, and make the point where no red service remains beyond it the first candidate to open. In the inspect view you can inspect each node further and walk the dependencies one hop at a time. The tagservice is the special key that identifies an APM service; if you attach the same key to the Host Map and to logs, you can jump from each node in the map to the logs and infrastructure views for the same service.
The Service Map earns its keep when you find an unknown callee
This view earns its keep when the design document and reality have drifted apart. Because the map is born from traces, a call to an external API that someone added, or a line to a service that was supposed to have been retired, appears without anyone redrawing the architecture diagram. Conversely, a line that should be there but is missing is a sign that traces are not arriving. If there is a period when the map cannot be drawn, the official documentation raises the possibility that complete traces including a root span were not available (as of September 2026, Source: Service Map). If you attach a service tag to a monitor, its status appears on the map, which also makes it an entry point for linking business metric monitors to services. The difference from the Host Map is the unit. The Host Map lines up machines as hexagons, while the Service Map lines up services, the unit of code, and the calls between them. Calls can get stuck even when the machines are healthy, and the reverse is also true, so the two maps are meant to be read on top of each other, not as substitutes.