Act
Destinations
Destinations are the systems MonitOps delivers to. Each has its own routing policy, queue and health.
Kinds of destination#
| Kind | What MonitOps delivers |
|---|---|
Ticketing | Open, update and close tickets as incidents open, escalate and resolve, under a policy such as severity at or above major |
Fault management | Raise and clear alarms in your fault-management format under the same identity as the incident |
Log platform | Forward masked, normalised logs with routing rules |
SIEM | Forward security-relevant events in the format your SIEM expects |
Administrators configure destinations. Each kind has its own article: Ticketing, Fault management and Log forwarding.
How it works#
Ticketing#
A ticketing destination has a policy that decides which incidents qualify: a minimum severity, the cause classes and a customer-impact flag.
- MonitOps opens one ticket per qualifying incident.
- It updates the ticket when severity or the leading cause changes.
- It closes the ticket on resolution, with the outcome.
- Ticket events appear on the incident timeline.
Ticket content is built from templates for create, update and close, with field mapping from the incident. A response path picks the external reference out of the destination's reply, and a status mapping translates between the destination's statuses and the incident's.
If a call to the destination ends with an uncertain result, MonitOps reads the ticket back from the destination to reconcile it before it retries.
Fault management#
A fault-management destination receives an alarm for an incident under the alarm identity of the leading firing alarm definition, with that definition's severity mapping (see Alarm definitions).
- The alarm is raised when the incident opens and cleared when it resolves, under the same identity.
- Escalation updates the same alarm.
- A disabled definition stops raising alarms but still clears the ones it raised.
- Alarms can be enabled and disabled individually in the console.
- MonitOps sends a periodic heartbeat, and can list the alarms it believes are active so the two sides can be resynchronised.
Log forwarding#
Routing rules choose which sources and signals go to each log destination. Every destination receives only masked, normalised records; there is no separate unmasked path. Logs that are forwarded are not sampled.
SIEM#
A SIEM destination receives security-relevant events in the format the SIEM expects.
Delivery#
Each destination has a persistent queue with retries. A slow or unavailable destination does not block the others or block ingestion, and delivery resumes when the destination returns. The queue's capacity is configured, and saturation is shown rather than hidden.
What you see in the console#
The destinations page lists each destination with its policy, backlog, errors and freshness. An incident shows the state of its ticket and its delivered alarm.
For INC-20931, a ticketing destination with policy severity at or above major opens one ticket when the incident opens, updates it if severity changes, and closes it when the incident resolves.
Limits and defaults#
- One ticket per qualifying incident.
- Ticket policy is set per destination.
- Forwarded logs are post-masking and post-normalisation.
Failure states#
| State | What the console shows |
|---|---|
| Destination slow or down | Backlog grows on that destination only; other destinations continue |
| Uncertain delivery result | Reconciled by reading back before any retry |
| Queue saturated | A saturation state on the destination |
| Delivery errors | Error count and last error on the destination |
Related#
Last updated October 2026