Model
Service map
The service map shows services, declared systems and the relationships between them, with the provenance of every relationship. It is built from traces and from what your administrators declare, and it is the path that correlation, impact analysis and cause assessment follow.
How it works#
Every relationship on the map is an edge between two entities, and every edge says where it came from.
| Kind | Source | What the map shows |
|---|---|---|
| Observed edge | Traces | When the edge was first seen and last seen |
| Declared edge | The declared-systems configuration | Who declared it |
Observed edges#
When a sender includes traces, a span in one service whose parent span is in another service creates or refreshes a directed edge from the caller to the callee. The edge records when it was first seen and is refreshed whenever new spans confirm it. Logs and service names alone never create edges: an edge exists because a request crossed a service boundary, not because two names appear in the same time window.
An observed edge that sees no spans for an inactivity window is closed. The window is 24 hours by default and can be configured. Before it closes, an edge that has not been observed recently fades on the map rather than being shown as current, and a closed edge is shown with the time it was last seen. A relationship that last appeared six days ago is therefore never drawn as if it were live.
Declared edges#
Declared edges come from the declared-systems configuration, and they name who declared them. They cover relationships that traces cannot show, for example a dependency on an external provider that does not send traces, or a service that sends logs only. See Declared systems.
When both exist#
Where a declared and an observed edge describe the same relationship, the declared edge stands and the observed one corroborates it. Observation never overrides a declaration, and a declaration does not hide what traffic shows.
Systems outside your estate#
Entities that are classified as external, for example the services of a collector operated by someone else, stay off the map and out of cause assessment unless an administrator maps them in. Edges that touch them stay off as well. Several sources can observe the same service without any of them gaining authority over its place on the map.
New services#
A service that starts sending telemetry and calls an existing service appears on the map with its edges, without configuration. If a new service starts sending traces that call order-api, a node and an observed edge appear with their first-seen time.
Impact analysis#
For a failing node, MonitOps lists the services downstream of it and the customer journeys that pass through it, with an explanation of the path. The list is computed from the map: a failing node's impact is exactly its downstream dependants. The incident shows the impact as soon as it is opened, and the same lists feed the incident's affected systems and journeys.
In INC-20931, payments-gw is failing. order-api calls it and checkout-web calls order-api, so both are downstream, and the Card checkout journey passes through all three.
The AI explanation of the impact is separate from the computed list. The computed impact is the source of truth, and the explanation can only describe journeys that the computed impact contains; it cannot add one.
Service context#
A service on the map carries the context an operator needs to act: the journeys it serves, who owns it and what changed recently. Opening a service leads to its logs, metrics and traces with source, environment and time already set.
What you see in the console#
Service context
Services and systems are nodes; observed edges are solid lines with the time they were last seen, declared edges are dashed and name their declarer, and an edge that has stopped being observed is drawn muted. Selecting a failing node shows its impact.
Limits and defaults#
| Item | Default |
|---|---|
| Observed edge closes after | 24 hours with no spans, configurable |
| Edge sources | Traces and declarations only |
| Declared versus observed | The declared edge stands, the observed one corroborates |
| External entities | Off the map until an administrator maps them in |
Failure states#
- A service that sends no traces has no observed edges. It appears on the map and its relationships stay declared or absent.
- An edge that has not been seen recently fades instead of disappearing without a trace. A stale map is visible as stale.
- An incident's candidate causes are limited to what the map contains. A missing edge can therefore hide a dependency, which is why declaring a relationship that traces cannot show matters.
Related#
Last updated October 2026