Alert configuration

[umar5]

I have a 20 alerts with different descriptions for the same node. I created one alert rule and, in the alert filter, I added those descriptions using OR conditions ( a-description OR b-description OR c-description) for that node. Is this the correct configuration? If not, what is the correct approach? Please let me know the best practice?

[Bruno Pires2]

Hi  @umar5 

Your configuration will work, but it is not considered best practice, especially when you already have many alerts and the list may grow or change over time.

Using multiple OR conditions on the description field is fragile because descriptions are free text and can change with tool updates or minor wording differences.

Recommended best practice in ServiceNow Event Management

1. Avoid filtering by description when possible
   Try to base the alert rule on stable attributes such as source, node, metric name, event type, resource, object, class, or severity. These fields are far less likely to change than description text.
2. Use patterns instead of many OR conditions
   If the alerts share a common keyword or structure, use contains, starts with, or regex rather than listing every description individually.
3. Normalize alerts at ingestion
   A better long term approach is to normalize the alerts when they are ingested, for example by mapping them to a derived field like alert category or signature. Then your alert rule can filter on that normalized field.
4. Split rules only when behavior differs
   Use separate rules only if the alerts require different actions such as different routing, severity, priority, or remediation. If the behavior is the same, keep one rule and improve the filter logic.

Rule of thumb
If the only difference between the alerts is the description, normalize or pattern match.
If the alerts require different handling, create separate rules.

Hope this helps.

[umar5]

If I use source, node, metric name, and event type, it will create incidents for secondary alerts as well? Is it recommended to create incidents for secondary alerts?
Secondary alerts also have different descriptions. So far, in the alert filter I have added descriptions only for primary alerts. We are newly integrating monitoring tools with ServiceNow.

[Bruno Pires2]

Hi @umar5 
Great question and very common when starting with Event Management
Short answer
No using source node metric name and event type does not automatically mean incidents will be created for secondary alerts and in general it is not recommended to create incidents for secondary alerts
The important concept here is to separate two different decisions
First which alerts should be correlated together
Second which alerts should actually create incidents
Using stable fields such as source node metric name and event type is the correct approach for correlation because it allows both primary and secondary alerts to be grouped under the same underlying issue This alone does not trigger incident creation
Incident creation should always be explicitly controlled with additional conditions such as
alert is primary
root cause flag is true
a specific alert category or signature that represents an actionable problem
With this setup
primary alerts create incidents
secondary alerts are correlated and provide context
incident noise and duplication are avoided
Creating incidents for secondary alerts is usually a bad practice because they represent symptoms or downstream effects This leads to unnecessary incidents and confusion for support teams
Your current approach of filtering by description to allow only primary alerts is understandable for an initial integration but it should be seen as temporary Description based logic is fragile and can easily break when wording changes
As the integration matures the best approach is to
identify or derive a reliable primary versus secondary indicator from the monitoring tool
normalize it during ingestion into a stable field
use that field for incident creation instead of descriptions
Rule of thumb
correlate broadly using stable attributes
create incidents only for alerts that require human action