# Service map > The viewer needs to know what depends on what, and which edge is unhealthy. - Canonical: https://patterns.konigi.com/dashboards/service-map - Group: Visual representation - Level: implementation - Status: published - Updated: September 10, 2026 - Also called: dependency graph, topology view, service graph --- ## Problem Checkout is failing. Checkout calls six things, and two of those call four more, and the person on call has been here three weeks and does not have that graph in their head. ## Solution Nodes for services, edges for calls between them, both derived from traces rather than from a diagram somebody drew. Datadog states the ambition plainly: decompose the application into its component services and draw the observed dependencies in real time. Nodes are services as they appear in instrumentation; edges are aggregate calls from one service to another. The word doing the work is *observed*. An architecture diagram in a wiki describes what someone intended eighteen months ago. A service map describes what actually made a request in the last few minutes, which is how teams discover the dependency nobody documented and the one everybody thought had been removed. Datadog's version ages a service or connection out after thirty days without traces, so the map has a definition of "gone" as well as of "new". Health goes on the node. Datadog colours service node borders red or yellow from a consolidated health state pulled from anomalies, paging monitors and incidents. That consolidation is the design decision worth copying: a topology view where every node shows five metrics is unreadable, and one where each node shows a single derived state is scannable in a second and then drilled into. Drawing the graph is easy. Laying it out is the hard part. Real service graphs are dense, cyclic and unbalanced, and generic force-directed layout produces a hairball that reorders itself on every refresh. A map a viewer cannot form a stable mental image of has failed regardless of how correct the edges are. ## Use when The estate is big enough that no one holds it in their head, calls cross team boundaries, and the question is "what is downstream of this" during an incident. ## Don't use when There are eight services and everyone knows them. Also don't use it as a monitoring surface: a topology view is a navigation and blast-radius tool, and a page that watches it continuously would be better off watching the four metrics that matter. ## Trade-offs Service maps only know what is instrumented, so an uninstrumented dependency is invisible in a view whose entire promise is completeness, which is worse than not having the view. Layout instability destroys recognition between visits. Aggregate edges hide direction of causality: a red edge tells you two services are having a bad time together and not which one started it. And at real scale the graph exceeds what a screen can carry, so every product has to pick a grouping, and the grouping determines what you are able to notice. ## Checklist - Is the map derived from traces, or from something a human maintains? - What is the time window, and does an edge disappear when calls stop? - Does a node carry one derived state, or several competing metrics? - Is the layout stable between refreshes and between people? - Can the viewer see call volume and error rate on an edge, not just its existence? - What happens at a hundred services, and what grouping is available? - Can you get from a node to that service's traces, logs and dashboards? - Are uninstrumented dependencies flagged, or silently absent? - Is direction of the call visible, and distinguishable from direction of blame? - Does a colourblind reader get the same health reading as everyone else? ## Compare **Datadog** builds the map automatically from APM traces, consolidates each service's health into one border colour, and ages entries out after thirty days of silence, so the graph maintains itself in both directions. **Jaeger** ships a plainer dependency view derived from the same span parent-child relationships, which is enough to answer "who calls this" without pretending to be a monitoring surface. **Grafana** approaches it through Tempo's service graph, assembled from span metrics, so the topology lives beside the dashboards rather than in a separate product. **Netdata** works at the host and container layer instead, mapping what is running where rather than what calls what, which answers a different question people often bring to the same screen. ## Related Trace waterfall is one instance of what this view aggregates, and the natural drill target. Host map is the same spatial idea applied to infrastructure rather than to calls. Drill-down is what a node click has to do. Semantic status color decides what a red node means. Overview then detail is the structure this pattern sits at the top of. ## Examples ### Grafana (Grafana Labs) The reference implementation for panel grids, template variables, and stat panels; most other tools are defined by how they differ from it. **Examples / Node graph panel** — captured September 10, 2026, Grafana Play (signed out; no version string exposed). operational, sparse density, dark theme, desktop-web. Seven services, and the panel is already too small to hold them. Three nodes are cut in half by the right edge and at least one more is somewhere past it, which is the force layout doing what force layouts do to a graph with more nodes than room. That is the hard part of this pattern and it is visible here at a scale of seven. Each node also carries four things at once: a number, a second number, and a ring split between a green arc and a red one. The legend names all four. A topology view where every node reports four measures is a view you read node by node, which is the opposite of what a map is for —one derived state per node is scannable in a second and drills into the rest. Here almost every ring is mostly red, so the channel that could have carried that state is saturated and distinguishes nothing. Hotspots in this capture: - [Service map](https://patterns.konigi.com/dashboards/service-map) *(this pattern)* — Nodes for services, edges for calls, both from instrumentation rather than from a diagram. - [Semantic status color](https://patterns.konigi.com/dashboards/semantic-status-color) — One node: two numbers inside and a success/error ring around it. Four measures, no verdict. - [Legend and series toggle](https://patterns.konigi.com/dashboards/legend-and-series-toggle) — Four series named for a graph with seven nodes, which is the legend doing more work than the map. - [Zoom and pan on time](https://patterns.konigi.com/dashboards/zoom-and-pan) — The only route to the nodes pushed off the right edge, and it doesn't move the rest of the page. ## Related patterns - [Trace waterfall](https://patterns.konigi.com/dashboards/trace-waterfall) — One request touched twenty services and the viewer needs to see where the time went. - [Host map](https://patterns.konigi.com/dashboards/host-map) — Hundreds of hosts; the viewer needs to spot the hot ones without a table of hundreds of rows. - [Drill-down](https://patterns.konigi.com/dashboards/drill-down) — The overview shows that something is wrong; the viewer needs to get to what, in one click. - [Semantic status color](https://patterns.konigi.com/dashboards/semantic-status-color) — State has to be readable before the number is. - [Overview then detail](https://patterns.konigi.com/dashboards/overview-then-detail) — The viewer needs to start wide and end narrow without losing their place. ## Sources - [Datadog, Service Map](https://docs.datadoghq.com/tracing/services/services_map/) - [OpenTelemetry, Traces](https://opentelemetry.io/docs/concepts/signals/traces/) - [Jaeger, Frontend UI](https://www.jaegertracing.io/docs/latest/frontend-ui/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.