Service map

The Service map (Observe → Service map) draws what calls what across your services, databases and external hosts, from the logs and traces you already send. It needs no tracing:

• Every service that logs is on the map, with its log volume and error rate, even without traces.
• Logs connect services in two ways, both drawn dashed and labelled inferred from logs:
• the order in which services appear within one request or correlation id;
• log fields that name the other side of a call: peer.service, db.system, an Envoy upstream (upstream_cluster, upstream_host), an nginx upstream_addr, or net.peer.name. A Kubernetes name such as outbound|8080||content-api.prod.svc.cluster.local resolves to the content-api service; db.system becomes a database; any other host becomes an external host.
• Traces add exact calls, latency and status wherever you send them, and win over what logs suggest for the same pair.

Use How the map works in the page header to open this page.

Read the map#

• Shapes tell you what a node is. A card with a server icon is a service, a cylinder is a database (from db.system.name or db.system, and db.namespace or db.name, on client spans), and a dashed hexagon with a globe is an external host (peer.service, server.address or net.peer.name on client spans that no instrumented service answered). A card with a dashed outline is a service seen only in logs: it shows its log volume and the share of error logs, and is coloured by that share.
• Health. A service's bar and outline, and every edge, are neutral when healthy, amber from 1 % errors and red from 5 %. Each node shows its requests and error rate; hover for p95.
• Edges go from caller to callee, left to right. Services that call each other are stacked in one column, and their calls are arcs on the right of the column. Two services calling each other share one edge with an arrow at each end.
• Width follows the call rate. Dashed edges are inferred from logs; when a span shows the same call, the edge is solid.
• eBPF on a card means the service was traced without code changes, by OpenTelemetry eBPF instrumentation. When such a service is named after its executable (python3.13, node), different services running it share one node: set OTEL_SERVICE_NAME on each process (see service names). When trace context is lost between hosts, the map still links a call to the service that listens on its address and port.
• Hover a node to light up its calls with their rate, error rate and p95; the rest fades.

Use the time range picker (up to 7 days), the Services filter (an edge stays when either end is chosen), Find a node, Edges from logs, and Hide quiet nodes (hides nodes with under 1 % of the busiest node's traffic unless they have errors). Scroll or pinch to zoom, drag to pan, and use the buttons at the bottom right to zoom or fit. The table under the map lists every edge with its rate, error rate and p95 latency. The map shows the busiest 300 edges and says when there were more.

Keyboard: Tab to a node or an edge, Enter to open it, Escape to close the panel.

Drill down#

• Click a node to open its panel: requests, error rate and p95, who calls it and what it calls, and buttons for its Traces, Logs, Metrics and Endpoints (a database opens its Statements on the Database page). Focus ± 1, 2 or 3 keeps only the node's neighbourhood on the map.
• Click an edge to open its traces. For a call between two services this is every trace with spans in both. For a database or an external host it is the caller's traces with that database system or host attribute. An edge inferred from request ids opens the stories of the two services in Explore; an edge from a log field opens the caller's logs with that field value.
• Every link keeps the time range you are looking at.

Show on map, from where you already are#

• Traces: with one service filtered, Show on map sits next to the filter chips. A trace's header has Services on map (15 minutes around the trace).
• Endpoints and Database: the detail panel of an endpoint or a statement has Show on map.
• Explore: hover a value of the service facet and click the map icon.
• Alerts: an incident's Related services card has Show on map, in the incident's window.
• Home: the Service map card shows the last hour's services, connections and the calls failing most.

Relationships#

Logthread keeps a topology graph of each workspace, updated every 10 minutes from your traces, request ids in logs, error patterns, alert rules, incidents and dashboards, and remembers the last 30 days. It holds names, counts, latency and time stamps only, never log or span content. A new workspace's graph fills in within about 10 minutes of its first data.

In the node panel of a service:

In the Relationships card under the map, for the whole workspace:

Incidents: related services and blast radius#

Every incident with a service has a Related services card: who called the service and what it depended on while the incident was open, with their error rates (from traces), and from the topology graph what can feel it (everything upstream) and what can cause it (everything downstream). Show on map opens the map focused on the service in the incident's window.

For AI agents and Pari#

The same relationship questions are available to AI agents as read-only MCP tools (topology_downstream, topology_upstream, topology_shared_dependencies, topology_downstream_patterns, topology_diff, topology_incident_clusters; see AI agents (MCP)) and to Pari, who sees names and counts only and links you to the Service map.

A request as a graph#

On a story card (Explore → Show full story) with a trace id, switch the timeline to Graph. Spans become bars on their service's lane, log events become diamonds on the same timeline, and arrows show each call from a parent span to a child span in another service, red when the child failed. Click a span to open it in the trace view, or a diamond to jump to that event in the list.

Next: be told when something breaks with Alerts.