Alert Rules: Defining Conditions
The first step to building your alert rule is defining a condition which you're looking to match in the incoming alerts. You can construct arguments with a set of conditions and Rule Groups with the logical operators AND, OR, NOT, NOR and NAND between them.
To learn what each field refers to, revisit the Alert Fields Guide here.
The following fields and supported operators can be used:
Alert Type, Incident Urgency, Day of Week
Supported Operators:
- ==
- !=
- Any in
- Not in
Example:
The above rule catches all non-critical alerts received on Saturday and Sunday.
Alert Time, Alert Date
Supported Operators:
- <=
- =>
- Between
Applied with Date/Time Objects as values.
Example:
The above rule catches all alerts received before 5PM between 13th August 2024 and 14th August 2024.
Message, Summary
Supported Operators:
- Equals
- Not Equal to
- Regex Match
- Regex Not Match
- Contains
- Not Contains
- Is Empty
- Is Not Empty
Applied with user specified text or regex expressions.
Example:
The above rule catches all alerts with infra mentioned anywhere in the Alert Message.
Entity ID
Supported Operators:
- Equals
- Not Equal to
- Contains
- Not Contains
- Is Empty
- Is Not Empty
Applied with user specified entity_id
string.
Example:
The above rule catches all alerts with the specified entity_id
.
Seconds Since Last Similar Incident
Applied with user specified number in seconds.
The limit goes up to 86400 (1 Day).
Example:
The above rule catches all similar alerts in the specified timeframe.
Payload Value Match and Payload Key Search
Using Alert Rules, you can also parse patterns around certain keys and values in the alert payload received and set action workflows when the pattern is matched. You can make use of the "Pick from Payload" option to fetch the key value from the raw payload.
A gist of the important rules are listed below -
Example:
The above rule catches all alerts whose severity key matches the value 1.
Example:
The above rule catches all alerts which possess a url key.