Service map

The service map draws your whole system from the traces you already send: every service, the databases and external APIs it calls, and the calls between services, including calls from one project into another. Services that never talk to each other appear as separate graphs.

Reading the map

• Nodes are services, databases and external hosts. Each shows requests, error rate and p95 latency. Nodes whose error rate is 1% or more are marked.
• Edges point from caller to callee. Dashed, darker edges cross projects.
• Frames group each connected set of services, labelled with its project.
• The Connections table below lists every edge with requests, error rate and latency percentiles.

How connections are found

There are two kinds of edges, both derived from spans:

• Service → service: a span whose parent belongs to a different service or project. A browser fetch whose traceparent reached a Worker is one; a Worker in one project calling a Worker in another is another.
• Service → database or external host: spans with db.system.name, and client spans with a peer or server.address that no instrumented service picked up.

Database and external nodes belong to the calling project, so two unrelated projects that both use MongoDB don't get merged into one graph. Edge numbers describe the callee side: its duration and status.

When a connection is missing

• Browser → API: the API's host must be in the script's data-propagate (or be the same origin), and the API must allow the traceparent header in CORS.
• Worker → Worker: both must be instrumented; outgoing fetches carry traceparent by default.
• Databases: wrap calls with trace() and set db.system.name. See Workers.
• The map covers the selected time range (24 hours by default), so a call that hasn't happened recently isn't shown.