Model
Declared systems
Declared systems are the part of the estate model that traffic cannot show: which platforms and providers exist, which services belong to them, which dependencies cannot be seen in traces and which customer journeys matter. They are tenant configuration written by administrators, and they combine with what MonitOps observes.
How it works#
MonitOps learns services and their calls from telemetry, and it learns nothing else about your estate unless it is told. Declarations fill that gap. A declaration states four kinds of fact.
| Fact | Why it has to be declared |
|---|---|
| Systems and components | A system such as a payment provider is not a deployable service, so no telemetry names it as one |
| Services grouped into systems | Telemetry names a service, but not which platform it belongs to |
| Declared edges | A dependency may not appear in traces, for example because one side does not send them |
| Journeys | A customer-facing flow is a statement about what customers do, not something spans can reveal |
A source can also contribute declarations. A provider source's configuration declares the system and the components it contributes, so adding that source adds those entities.
Declarations#
Systems, components and services#
| Field | Meaning |
|---|---|
| Key | The stable identifier of the entity, in mono wherever it is shown, for example order-api or payments-gw |
| Kind | system, component or service |
| Display name | The name shown in the console |
| Parent | The system a component or service belongs to, if any |
| Criticality | How much the entity matters to the business. Incident severity uses it as an input; see Severity |
A system is a declared platform or external provider that services depend on. A component is a part of a system, such as the API or the login of a provider. A service is a deployable component, and it appears on the map without being declared as soon as it sends telemetry. Declaring a service adds what telemetry cannot: its parent system and its criticality.
Edges#
A declared edge has a direction, from the entity that depends to the entity depended on, and it names who declared it. It appears on the Service map as a dashed line. Checks can be declared as edges to their targets, so that a failing check is placed next to the thing it tests.
Journeys#
| Field | Meaning |
|---|---|
| Key | The stable identifier of the journey |
| Name | The name shown in the console, for example Card checkout |
| Customer-facing | Whether customers experience the journey. Customer-facing journeys raise incident severity |
| Path | The ordered entities the journey passes through |
The path of Card checkout in the sample estate is checkout-web, then order-api, then payments-gw. A journey is affected when any entity on its path is affected, and this is how an incident lists the journeys it impacts. Order tracking is a second journey in the sample estate.
Owners#
Incidents show the owners of the affected services and systems, so that the right people are named with the problem. See Incidents.
How declarations and observations combine#
- Services appear without declaration. Anything that sends telemetry is a service. Declaring it adds context.
- Edges merge by relationship. Where a declared and an observed edge describe the same relationship, the declared one stands and the observed one corroborates it.
- Edges fade independently. Only observed edges close after an inactivity window; a declared edge stands because someone stated it.
- Declarations are not guesses. A name seen in a log line never becomes a system or an edge. Systems, components and journeys exist because they were declared.
- Source membership is configuration. Which system a source belongs to, and whether its services take part in correlation, are fixed in trusted configuration, not by the sender.
What you see in the console#
Systems and services appear on the service map and on Overview, with their health. An incident lists its affected systems, journeys and owners, and its impact panel lists downstream dependants. A declared edge names its declarer. A journey that passes through a failing entity is listed on the incident.
Changing a declaration#
Declarations change the model that correlation and cause assessment use, so a change is deliberate.
- Edit the declaration in the tenant configuration.
- Validate it before applying it. Validation reports problems per object rather than failing the whole change.
- Apply it. Cause assessment considers candidates as the map stood when each incident was opened, so a change applies to incidents opened after it.
Failure states#
| State | Effect |
|---|---|
| A relationship exists but is neither declared nor in traces | The map omits it and cause assessment cannot follow it |
| A service has no declared parent | It appears on the map without a system around it |
Related#
Last updated October 2026