Administer
Deployment and operations
MonitOps runs as a dedicated environment for each customer, operated by us, in a region agreed with you. Your telemetry, incidents and audit records stay in that environment and are not shared with other customers.
Environment#
Region and data residency, sizing and the upgrade process are agreed before installation.
Upgrades#
Upgrades are carried out by us as an operated service, with announced maintenance windows.
Availability#
Recovery time and acceptable data loss depend on the deployment architecture, replication and recovery procedures. They are agreed for each deployment.
| Event | Arrangement |
|---|---|
| Zone loss | Availability-zone redundancy and failover are defined in the deployment design |
| Region loss | Disaster recovery arrangements, including any second-region deployment, are agreed with you subject to data residency requirements |
Recovery objectives are validated through recovery drills before service commitments are made.
Retention#
Raw telemetry is kept for 90 days by default. Aggregates used by reports are kept longer. Retention is agreed per deployment, as one schedule for all the data the deployment stores.
Language model#
The copilot and the investigator call a language model endpoint agreed for the deployment, including its provider and region. Your data is not used to train models. The model reads data only through permission-checked, bounded tools; it cannot run arbitrary queries, and it never sets a confidence score, a cause class or an approval.
Data handling#
Personal data is masked before it is stored or forwarded (see Masking). Forwarding to other systems uses a persistent queue for each destination, so one slow destination does not block the others (see Destinations).
Self-monitoring#
MonitOps monitors its own components and shows their health alongside yours. The console shows:
| Condition | Where it appears |
|---|---|
| Ingestion gaps | On the affected source |
| Stale sources | On the source, as acquisition freshness |
| Integration failures | On the integration or destination |
| Backlogs | On the destination's queue |
| Degraded capabilities | As a degraded state on the capability |
A degraded capability keeps the same contracts. If the investigator is unavailable, the computed ranking still appears, marked as such (see Cause assessment). If the language model endpoint is unavailable, the copilot says so while detection and correlation continue.
What you see in the console#
Source health, destination backlogs and degraded states appear in the console as product states. They are not hidden in operator-only tooling.
Limits and defaults#
| Item | Default | Agreed per deployment |
|---|---|---|
| Raw telemetry retention | 90 days | Yes |
| Aggregate retention | Longer than raw | Yes |
| Region and residency | None assumed | Yes |
| Language model provider and region | None assumed | Yes |
| Recovery objectives | Validated by drills | Yes |
Failure states#
The failure states of individual capabilities are documented where the capability is described: Source health, Cause assessment and Copilot.
Related#
Last updated October 2026