Getting started
Concepts
MonitOps uses a small number of terms consistently across the console, the copilot and the API. This article defines each term and shows how the entities connect, so that an alert, an incident or a cause assessment can be read without guessing what it refers to.
How it works#
Everything in MonitOps belongs to a tenant. A tenant is the isolation and authorization scope for a customer's operational data and configuration: membership grants access within it, and every query, evidence link and copilot tool is scoped to it.
Inside a tenant, data arrives from sources. A source sends telemetry with its own credential, and that credential fixes which tenant and source the data belongs to. A sender cannot override either. Within that boundary, the telemetry names the services it describes, and MonitOps builds the model of your estate from it.
| Term | Meaning |
|---|---|
source | A system that sends telemetry to MonitOps. Each source has its own credential and declares its environment |
service | A deployable component, identified by its service name in the telemetry it sends, for example order-api |
system | A declared platform or external provider that services depend on, such as a CRM or a payment provider, for example payments-gw |
component | A part of a declared system, such as the API or the login of a provider |
journey | A customer-facing flow across services and systems, such as card checkout |
environment | The operational scope of a service's health, signals and correlation, set by the sender or enforced by the source |
alarm definition | A rule that evaluates a signal. Every evaluation records the definition version that produced it |
alert | One firing evaluation, with its severity |
incident | A set of alerts grouped by MonitOps with the reason they were grouped, or opened by an operator |
cause assessment | Ranked candidate causes for an incident, each with relative confidence, cause class and evidence |
action, run | A catalogued recovery procedure, and one approved execution of it |
destination | A system MonitOps delivers to: ticketing, fault management, log platform or SIEM |
Services, systems and components#
A service is identified by the service name, and its namespace when the telemetry carries one. Identity is logical: a new release or a new running instance of order-api is not a new service. The environment scopes health and correlation, so the same service in two environments is not merged into one state.
Systems and components are declared by administrators, or contributed by a source's configuration. A service that starts sending telemetry appears without any registration; a system or a journey exists because someone declared it. Declared systems describes what is declared, and Service map describes how declarations and observations combine.
Telemetry never creates a system by itself. A name seen in a log line is not an edge or a dependency. Dependencies come from traces and from declarations.
Alerts and their states#
An alarm definition evaluates a signal. A firing evaluation becomes an alert. An alert is in one of three states.
| State | Meaning |
|---|---|
| firing | The evaluation is currently firing. The alert has a severity: critical, major, minor or warning |
| cleared | The condition has recovered. The alert keeps the severity it had, shown beside a cleared label, so the record shows what it was |
| predicted | A forecast crosses a limit within its horizon. The alert shows a Predicted badge and the severity it would have, is never counted as a current failure and is never grouped with current failures |
Severity levels are described in Severity. Definitions are described in Alarm definitions.
Incidents and their states#
An incident is a set of alerts that share a time window and a path on the service map, or one an operator opened. It states why its alerts were grouped.
| State | Meaning |
|---|---|
| open | The incident exists and has not been acknowledged |
| acknowledged | An operator has acknowledged it |
| resolved | Its alerts have cleared or, after an action, recovery has been verified |
Each incident carries a priority from P1 to P4, its affected systems and journeys, and its owners. Every detection, grouping, assessment, question, recommendation, approval, run and verification is recorded on the incident timeline with identity and time. Incidents describes grouping and the timeline.
Cause assessment, confidence and class#
For each incident MonitOps ranks candidate causes. Each candidate has a relative confidence, which ranks candidates against each other, and a cause class: application, integration or provider. The investigator is the AI step that tries to confirm or refute the top candidates with cited evidence; the copilot is the question-and-answer panel that uses the same permission-checked tools as the console. See Cause assessment and Copilot.
Actions, runs and destinations#
An action is a procedure from a catalogue your team maintains. A run is one approved execution of an action, recorded with requester, approver, timing, outcome and verification result. A destination is a system MonitOps delivers to. See Actions and Destinations.
Rules that apply throughout#
A few behaviours are the same wherever you meet them, and the articles rely on them.
- Evidence comes first. An explanation cites the query, provider incident, check result or change record it came from, and each piece of evidence reopens its source. When the evidence is thin, MonitOps says so instead of forcing a cause.
- Code decides, the AI proposes. The AI investigator and the copilot propose and explain. Scores, cause classes, catalogue membership, roles and approvals are checked in code, and the AI cannot set a score, a confidence or a class.
- Permissions are enforced in the tools. The console, the API and the copilot read through the same permission-checked paths. A question cannot widen access.
- Predictions are not failures. A predicted breach is shown with a Predicted badge and the severity it would have. It is never counted as a current failure and never grouped with current failures.
- Recovery is verified, not assumed. An incident resolves after an action only when fresh checks meet the action's recovery criteria, not because the command returned.
- Degraded keeps the contract. If the language model endpoint is unavailable, detection, correlation and the computed cause ranking continue, and the affected blocks say they are unavailable.
One incident through the lifecycle#
Examples in the documentation use one sample estate: checkout-web, order-api, payments-gw (an external payment provider), crm-sync and contact-centre. Excerpts that show the console are labelled Simulated data.
The sample incident, INC-20931, shows the lifecycle in order. payments-gw starts failing during card checkout. The order-api error rate leaves its baseline band at 14:02:11 and seven alerts from different detectors fire. MonitOps groups them into one P1 incident with the facts that caused the grouping: the same 90-second window, and the shared path checkout-web, order-api, payments-gw. A crm-sync latency warning stays separate because it is not on that path, and the incident says so.
The cause assessment ranks payments-gw first, with cause class provider, and order-api second, with cause class integration, each with its evidence. An operator asks the copilot whether the problem is the provider or the team's own, and gets an answer that cites that evidence. The recommended action is requested, approved by a second person and run, and the incident resolves only when fresh checks confirm recovery.
What you see in the console#
Identifiers are set in a monospaced typeface wherever they appear: service names such as order-api, incident numbers such as INC-20931, run numbers, credential identifiers, timestamps, queries and log lines. Status is never shown by colour alone: severity, priority and health appear with a label as well. The copilot and the API use the same terms as the console, and technical identifiers stay unchanged in Thai and English.
Related#
Last updated October 2026