Act
Fault management
A fault-management destination delivers an incident to your fault-management system as an alarm. MonitOps raises the alarm when the incident opens, updates it when the incident escalates and clears it when the incident resolves, always under the same alarm identity.
How it works#
Alarms are delivered over REST in the format your fault-management system defines. SNMP is not used.
Alarm identity and severity#
An alarm definition carries an alarm identity and a severity mapping (see Alarm definitions). Definitions do not raise alarms themselves: a firing definition produces an alert, the alert joins an incident, and the destination then maps the incident to an alarm using the leading firing definition. The alarm takes that definition's alarm identity and severity mapping.
Raise, escalate, clear#
| Incident event | Alarm action |
|---|---|
| The incident opens | The alarm is raised |
| The incident escalates | The same alarm is updated |
| The incident resolves | The alarm is cleared |
Raise and clear use the same alarm identity, so your fault-management system can match them without any other correlation.
Disabled definitions#
Disabling a definition stops it raising new alarms. It still clears the alarms it raised. Deleting a definition is a soft delete, and delivered alarms keep referencing the version they used.
Heartbeat and resync#
MonitOps sends a periodic heartbeat to the fault-management system. It can also list the alarms it believes are active, so the two sides can compare and be resynchronised after an interruption.
Per-alarm control#
Alarms can be enabled and disabled individually in the console.
Delivery#
The destination has its own persistent queue with retries. If the fault-management system refuses an alarm, the refusal and its message are recorded as a delivery error on the destination. An uncertain result is reconciled before any retry (see Destinations).
What you see in the console#
The destinations page shows the backlog, errors and freshness of the fault-management destination. An incident shows its delivered alarm and the state of that alarm.
For INC-20931, the alarm is raised under the identity of the leading firing definition when the incident opens, updated if the incident escalates, and cleared when the incident resolves.
Limits and defaults#
- One alarm identity per incident: the identity of the leading firing definition.
- Alarms are enabled and disabled individually.
- The format of the alarm is the one your fault-management system defines.
Failure states#
| State | What happens |
|---|---|
| System unavailable | The backlog grows on that destination only; delivery resumes when it returns |
| Alarm refused | The refusal appears as a delivery error with the last error |
| Queue saturated | A saturation state is shown |
| Disagreement about active alarms | The list of active alarms is used to resynchronise |
Related#
Last updated October 2026