Skip to main content

​
Overview

Alert Rules allow you to process incoming alerts before they create incidents. You can suppress noisy alerts, adjust severity levels, add tags for routing, or modify alert fields. Rules are evaluated in real-time as alerts arrive, giving you fine-grained control over your incident pipeline.

Suppress Noise

Drop unwanted alerts from development environments or known issues

Normalize Severity

Standardize severity levels across different monitoring tools

Enrich Alerts

Add tags and metadata for better routing and categorization

Transform Fields

Modify alert properties before incident creation

​
How Alert Rules Work

Alert Received
       ↓
Rules Evaluated (by priority)
       ↓
┌──────┴──────┐
│             │
Suppressed    Modified
    ↓             ↓
  Dropped    Create Incident
              (with changes)
Rules are evaluated in priority order (lower number = higher priority). When a rule matches:
  1. Its actions are applied to the alert
  2. If stopProcessing is enabled, no more rules are evaluated
  3. If suppressed, the alert is dropped immediately

​
Viewing Alert Rules

The Alert Rules page displays all your configured rules:
ColumnDescription
RuleName and description
PriorityEvaluation order (lower = first)
ConditionsNumber of matching conditions
ActionsNumber of actions to apply
StopWhether to stop evaluating other rules
StatusActive or Inactive

​
Creating Alert Rules

1

Open Create Dialog

Click the Add Rule button
2

Configure Basic Info

In the Basic Info tab:
  • Name — Descriptive rule name
  • Description — Explain what this rule does
  • Priority — Lower numbers evaluate first (default: 100)
  • Stop Processing — Stop evaluating other rules if this matches
3

Define Conditions

In the Conditions tab:
  • Add conditions that must match for the rule to trigger
  • Use ALL (AND) and ANY (OR) logic groups
4

Configure Actions

In the Actions tab:
  • Add actions to apply when conditions match
  • Actions execute in order
5

Save Rule

Click Create to save your rule

​
Understanding Conditions

Conditions determine when a rule triggers. You can combine conditions using AND/OR logic.

​
Condition Logic

Every condition in the ALL group must match.Example: Alert must be from production AND be critical severity
ALL:
  - environment equals "production"
  - severity equals "critical"
If no conditions are defined, the rule always matches every incoming alert.

​
Available Fields

FieldDescription
severityAlert severity level
hostAffected hostname
serviceService or application name
titleAlert title
descriptionAlert description
sourceSource integration
statusAlert status
environmentEnvironment tag
regionRegion tag
tags.*Any tag value (e.g., tags.team)
extra.*Any extra field (e.g., extra.customField)

​
Condition Operators

OperatorDescriptionExample
equalsExact match (case-insensitive)severity equals "critical"
not_equalsDoes not matchenvironment not_equals "production"
containsContains substringtitle contains "error"
not_containsDoes not containtitle not_contains "test"
matchesRegex pattern matchtitle matches "^ERROR.*"
inValue in liststatus in "triggered,firing"
not_inValue not in listseverity not_in "info,ok"
existsField existstags.team exists
greater_thanNumeric greater thanvalue greater_than 90
less_thanNumeric less thanvalue less_than 10
Use tags.* to match on custom tags from your monitoring tools. For example, tags.customer equals "acme" matches alerts tagged with customer=acme.

​
Configuring Actions

Actions define what happens when a rule matches.

​
Available Actions

Type: suppressDrops the alert entirely. No incident is created.Use Case: Suppress alerts from development environments or known false positives.
Action: suppress
Effect: Alert is dropped, no incident created
Type: setPriorityOverrides the alert’s priority level.Options: P1 (Critical), P2 (High), P3 (Medium), P4 (Low), P5 (Info)Use Case: Escalate or de-escalate alerts based on context.
Action: setPriority
Value: P1
Effect: Alert priority set to Critical
Type: addTagsAdds tags to the alert for routing and categorization.Use Case: Tag alerts for team routing or tracking.
Action: addTags
Tags: team=platform, escalate=true
Effect: Tags added to alert
Type: setFieldSets or overrides any alert field value.Use Case: Normalize field values across different sources.
Action: setField
Field: source
Value: internal-monitoring
Effect: Source field set to "internal-monitoring"

​
Multiple Actions

You can combine multiple actions in a single rule. Actions execute in order.
Rule: Escalate and tag infrastructure alertsActions:
  1. setPriority: P1 — Escalate to critical
  2. addTags: team=infrastructure — Route to infrastructure team
  3. addTags: auto_escalated=true — Track automatic escalation
All three actions apply to matching alerts.

​
Priority and Stop Processing

​
Rule Priority

Rules are evaluated in priority order (lower number = higher priority):
PriorityEvaluation Order
1First
10Second
100Third
1000Last
Use priority to control which rules take precedence. For example, a suppression rule at priority 1 will drop alerts before enrichment rules at priority 100 can process them.

​
Stop Processing

When Stop Processing is enabled:
  • If the rule matches, no subsequent rules are evaluated
  • Useful for definitive actions like suppression
Rule 1 (Priority 1, Stop Processing: ON):
  • Condition: environment equals "development"
  • Action: suppress
Rule 2 (Priority 100):
  • Condition: severity equals "critical"
  • Action: setPriority: P1
Result: Development alerts are suppressed immediately. Rule 2 never sees them because Rule 1 stops processing.

​
Common Use Cases

Goal: Drop all alerts from non-production environmentsConditions:
ANY:
  - environment equals "development"
  - environment equals "staging"
  - environment equals "test"
Actions:
  • suppress
Settings:
  • Priority: 1 (evaluate first)
  • Stop Processing: Yes
Goal: Make all database alerts critical priorityConditions:
ALL:
  - service contains "database"
ANY:
  - severity equals "critical"
  - severity equals "high"
Actions:
  • setPriority: P1
  • addTags: team=dba
Goal: Add routing tags based on host prefixConditions:
ALL:
  - host matches "^acme-.*"
Actions:
  • addTags: customer=acme
  • addTags: tier=premium
Goal: Standardize severity from specific integrationConditions:
ALL:
  - source equals "datadog"
  - severity equals "error"
Actions:
  • setPriority: P2
  • setField: severity = "high"
Goal: Drop alerts during known maintenanceConditions:
ALL:
  - tags.maintenance_window exists
Actions:
  • suppress
Settings:
  • Priority: 1
  • Stop Processing: Yes
Goal: Assign default team when not specifiedConditions:
ALL:
  - tags.team not_exists
  - environment equals "production"
Actions:
  • addTags: team=on-call

​
Managing Rules

​
Editing Rules

  1. Click the three-dot menu (⋮) on a rule
  2. Select Edit
  3. Modify conditions, actions, or settings
  4. Save changes

​
Duplicating Rules

Create a copy of an existing rule:
  1. Click the three-dot menu
  2. Select Duplicate
  3. Modify the copy as needed
  4. Save as a new rule
Duplicating is useful when you need similar rules with minor variations.

​
Activating/Deactivating Rules

Toggle rule status without deleting:
  • Active: Rule is evaluated on incoming alerts
  • Inactive: Rule is skipped during evaluation
Edit the rule and toggle the status, or use the API to change isActive.

​
Deleting Rules

  1. Click the three-dot menu
  2. Select Delete
  3. Confirm deletion
Deleted rules cannot be recovered. Consider deactivating instead.

​
Rule Evaluation Flow

1

Alert Received

Webhook processor receives incoming alert
2

Build Context

Alert fields are extracted into evaluation context:
  • Direct fields (severity, host, service, etc.)
  • Tags (tags.*)
  • Extra fields (extra.*)
3

Get Active Rules

All active rules for the tenant are loaded, ordered by priority
4

Evaluate Each Rule

For each rule (in priority order):
  • Check ALL conditions (must all match)
  • Check ANY conditions (at least one must match)
  • If both groups satisfied → rule matches
5

Apply Actions

For matching rules:
  • Execute actions in order
  • If suppressed → drop alert
  • If stop processing → skip remaining rules
6

Create Incident

If not suppressed, create incident with modifications applied

​
Best Practices

Reserve low numbers (1-10) for critical rules like suppression. Use higher numbers (100+) for enrichment rules.
More specific rules should have higher priority (lower number) than general rules.
Create rules as inactive first. Review incoming alerts to verify conditions match expected alerts before activating.
Enable stop processing for definitive actions (suppress). Leave it off for additive rules (add tags) so multiple rules can enhance alerts.
Use the description field to explain why the rule exists and what it’s meant to catch.
Audit rules regularly. Remove rules for retired services or outdated conditions.

​
Troubleshooting

  1. Verify rule is Active
  2. Check condition field names match your alert data
  3. Use webhook samples to see actual field values
  4. Test regex patterns separately
  5. Check if a higher-priority rule is stopping processing
  1. Check for active rules with suppress action
  2. Review rules with highest priority (lowest number)
  3. Look for broad conditions that might match unintended alerts
  4. Temporarily deactivate suspect rules to identify the culprit
  1. Verify rule conditions are matching
  2. Check action type is addTags
  3. Confirm tag key-value format is correct
  4. Review rule priority (might be overwritten by later rule)
  1. Verify setPriority action is configured
  2. Check priority value format (P1, P2, etc.)
  3. Look for conflicting rules that might set different priority
  1. Test regex pattern in a regex tester
  2. Remember patterns are case-insensitive
  3. Escape special characters properly
  4. Check for leading/trailing whitespace in field values

​
Quick Reference

​
Condition Operators

OperatorTypeDescription
equalsStringExact match
not_equalsStringNot equal
containsStringSubstring match
not_containsStringNo substring
matchesRegexPattern match
inListValue in list
not_inListValue not in list
existsBooleanField exists
greater_thanNumericGreater than
less_thanNumericLess than

​
Action Types

ActionEffect
suppressDrop alert
setPriorityOverride priority (P1-P5)
addTagsAdd key-value tags
setFieldSet/override field value

​
Priority Guidelines

RangeUse Case
1-10Suppression rules
11-50Critical modifications
51-100Standard processing
101-500Enrichment/tagging
501+Catch-all rules