Incidents and correlation

An incident is a set of alerts grouped by MonitOps, with the reason they were grouped, or an incident opened by an operator. Alerts that share a time window and a path on the service map are grouped into one incident, with the facts that caused the grouping.

How it works#

Correlation looks at alerts from every detector together: baseline departures, state rules, probe failures and provider status. Alerts that fall within one time window and are connected by a path on the service map become one incident (see Service map). Correlation is chronological, so it waits until every detector has observed an alert's time before it decides.

Grouping facts#

An incident lists the alerts grouped by MonitOps and the facts that grouped them: the window and the shared topology path. For INC-20931 the card reads:

Grouped by MonitOps · 7
Same 90 s window · shared path checkout-web → order-api → payments-gw

Each of the seven alerts shows its detector and the time it fired.

Alerts that stayed separate#

Alerts nearby that did not join the incident are shown beside it with the fact that failed. In the sample, a crm-sync latency warning stayed separate because it is not on the shared path. An operator can add a separate alert to the incident.

The raw alert record#

The raw alerts are always kept. Grouping never replaces them, so an alert can be opened from the incident to see its evaluation, the definition version that fired it and the chart (see Alarm definitions).

Lifecycle#

State	Meaning
Open	MonitOps has grouped alerts, or an operator has opened the incident
Acknowledged	An operator has acknowledged the incident
Resolved	The alerts have cleared or, after an action, recovery has been verified

After an action, an incident resolves only when the action's recovery criteria are met (see Actions). A cleared alert keeps its original severity beside a cleared label.

Priority and impact#

Each incident carries a priority from P1 to P4 and a severity (see Severity). The incident shows:

• affected systems and journeys, such as the Card checkout and Order tracking journeys in INC-20931;
• owners;
• an impact panel listing the downstream dependants of the failing node, with an explanation of the path.

Impact appears on the incident as soon as it is opened.

The timeline#

Every event on an incident is recorded on its timeline with identity and time. The timeline is the audit trail.

Event type	Recorded when
Detection	An alert fires
Grouping	Alerts are grouped, or an operator adds one
Assessment	A cause assessment is produced, re-run or marked insufficient
Question	Someone asks the copilot about the incident
Recommendation	MonitOps recommends an action
Approval	An action is approved or rejected
Run	An action run starts and ends
Verification	Recovery is checked against the action's criteria
Acknowledgement	An operator acknowledges the incident
Resolution	The incident resolves

Severity changes and destination events, such as a ticket opening, also appear on the timeline.

What you see in the console#

Step 3 of the sample shows the incident at 14:02:40: INC-20931, P1, severity major, with seven grouped alerts, one separate alert and the two affected journeys.

Limits and defaults#

• List pages hold 50 incidents by default and at most 200.
• The grouping window and path rules are applied by MonitOps; the incident shows which facts applied rather than a score.

Failure states#

State	What the console shows
Alert stayed separate	The failed grouping fact, with an option to add the alert
Recovery not confirmed	The incident stays open and says why (see Actions)

Related#

• Alarm definitions
• Cause assessment
• Severity
• Actions
• Service map