Alert Rules

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:

Its actions are applied to the alert
If stopProcessing is enabled, no more rules are evaluated
If suppressed, the alert is dropped immediately

Viewing Alert Rules

The Alert Rules page displays all your configured rules:

Column	Description
Rule	Name and description
Priority	Evaluation order (lower = first)
Conditions	Number of matching conditions
Actions	Number of actions to apply
Stop	Whether to stop evaluating other rules
Status	Active or Inactive

Creating Alert Rules

Open Create Dialog

Click the Add Rule button

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

Define Conditions

In the Conditions tab:

Add conditions that must match for the rule to trigger
Use ALL (AND) and ANY (OR) logic groups

Configure Actions

In the Actions tab:

Add actions to apply when conditions match
Actions execute in order

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

ALL Conditions (AND)
ANY Conditions (OR)
Combined 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"

At least one condition in the ANY group must match.Example: Alert is about CPU OR memory

ANY:
  - title contains "CPU"
  - title contains "memory"

When both ALL and ANY groups exist, both must be satisfied.Example: Production alert about CPU or memory

ALL:
  - environment equals "production"
ANY:
  - title contains "CPU"
  - title contains "memory"

This matches production alerts that mention either CPU or memory.

If no conditions are defined, the rule always matches every incoming alert.

Available Fields

Field	Description
`severity`	Alert severity level
`host`	Affected hostname
`service`	Service or application name
`title`	Alert title
`description`	Alert description
`source`	Source integration
`status`	Alert status
`environment`	Environment tag
`region`	Region tag
`tags.*`	Any tag value (e.g., `tags.team`)
`extra.*`	Any extra field (e.g., `extra.customField`)

Condition Operators

Operator	Description	Example
`equals`	Exact match (case-insensitive)	`severity equals "critical"`
`not_equals`	Does not match	`environment not_equals "production"`
`contains`	Contains substring	`title contains "error"`
`not_contains`	Does not contain	`title not_contains "test"`
`matches`	Regex pattern match	`title matches "^ERROR.*"`
`in`	Value in list	`status in "triggered,firing"`
`not_in`	Value not in list	`severity not_in "info,ok"`
`exists`	Field exists	`tags.team exists`
`greater_than`	Numeric greater than	`value greater_than 90`
`less_than`	Numeric less than	`value 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

Suppress (Drop Alert)

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

Set Priority

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

Add Tags

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

Set Field

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.

Example: Multi-Action Rule

Rule: Escalate and tag infrastructure alertsActions:

setPriority: P1 — Escalate to critical
addTags: team=infrastructure — Route to infrastructure team
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):

Priority	Evaluation Order
1	First
10	Second
100	Third
1000	Last

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

Example: Stop Processing

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

Suppress Development Alerts

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

Escalate Database Alerts

Goal: Make all database alerts critical priorityConditions:

ALL:
  - service contains "database"
ANY:
  - severity equals "critical"
  - severity equals "high"

Actions:

setPriority: P1
addTags: team=dba

Tag by Customer

Goal: Add routing tags based on host prefixConditions:

ALL:
  - host matches "^acme-.*"

Actions:

addTags: customer=acme
addTags: tier=premium

Normalize Vendor Severities

Goal: Standardize severity from specific integrationConditions:

ALL:
  - source equals "datadog"
  - severity equals "error"

Actions:

setPriority: P2
setField: severity = "high"

Suppress Maintenance Alerts

Goal: Drop alerts during known maintenanceConditions:

ALL:
  - tags.maintenance_window exists

Actions:

suppress

Settings:

Priority: 1
Stop Processing: Yes

Auto-Tag Missing Team

Goal: Assign default team when not specifiedConditions:

ALL:
  - tags.team not_exists
  - environment equals "production"

Actions:

addTags: team=on-call

Managing Rules

Editing Rules

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

Duplicating Rules

Create a copy of an existing rule:

Click the three-dot menu
Select Duplicate
Modify the copy as needed
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

Click the three-dot menu
Select Delete
Confirm deletion

Deleted rules cannot be recovered. Consider deactivating instead.

Rule Evaluation Flow

Alert Received

Webhook processor receives incoming alert

Build Context

Alert fields are extracted into evaluation context:

Direct fields (severity, host, service, etc.)
Tags (tags.*)
Extra fields (extra.*)

Get Active Rules

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

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

Apply Actions

For matching rules:

Execute actions in order
If suppressed → drop alert
If stop processing → skip remaining rules

Create Incident

If not suppressed, create incident with modifications applied

Best Practices

Use Meaningful Priorities

Reserve low numbers (1-10) for critical rules like suppression. Use higher numbers (100+) for enrichment rules.

Start Specific, Then General

More specific rules should have higher priority (lower number) than general rules.

Test Before Activating

Create rules as inactive first. Review incoming alerts to verify conditions match expected alerts before activating.

Use Stop Processing Wisely

Enable stop processing for definitive actions (suppress). Leave it off for additive rules (add tags) so multiple rules can enhance alerts.

Document Your Rules

Use the description field to explain why the rule exists and what it’s meant to catch.

Review Rules Periodically

Audit rules regularly. Remove rules for retired services or outdated conditions.

Troubleshooting

Rule not matching expected alerts

Verify rule is Active
Check condition field names match your alert data
Use webhook samples to see actual field values
Test regex patterns separately
Check if a higher-priority rule is stopping processing

Alerts being unexpectedly suppressed

Check for active rules with suppress action
Review rules with highest priority (lowest number)
Look for broad conditions that might match unintended alerts
Temporarily deactivate suspect rules to identify the culprit

Tags not appearing on incidents

Verify rule conditions are matching
Check action type is addTags
Confirm tag key-value format is correct
Review rule priority (might be overwritten by later rule)

Priority not being set

Verify setPriority action is configured
Check priority value format (P1, P2, etc.)
Look for conflicting rules that might set different priority

Regex not matching

Test regex pattern in a regex tester
Remember patterns are case-insensitive
Escape special characters properly
Check for leading/trailing whitespace in field values

Quick Reference

Condition Operators

Operator	Type	Description
`equals`	String	Exact match
`not_equals`	String	Not equal
`contains`	String	Substring match
`not_contains`	String	No substring
`matches`	Regex	Pattern match
`in`	List	Value in list
`not_in`	List	Value not in list
`exists`	Boolean	Field exists
`greater_than`	Numeric	Greater than
`less_than`	Numeric	Less than

Action Types

Action	Effect
`suppress`	Drop alert
`setPriority`	Override priority (P1-P5)
`addTags`	Add key-value tags
`setField`	Set/override field value

Priority Guidelines

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

Getting started

Analytics

Synthetics

Management

Integrations

Synthetics

Configuration

Access Management

Overview

Suppress Noise

Normalize Severity

Enrich Alerts

Transform Fields

How Alert Rules Work

Viewing Alert Rules

Creating Alert Rules

Understanding Conditions

Condition Logic

Available Fields

Condition Operators

Configuring Actions

Available Actions

Multiple Actions

Priority and Stop Processing

Rule Priority

Stop Processing

Common Use Cases

Managing Rules

Editing Rules

Duplicating Rules

Activating/Deactivating Rules

Deleting Rules

Rule Evaluation Flow

Best Practices

Troubleshooting

Quick Reference

Condition Operators

Action Types

Priority Guidelines

​Overview

Suppress Noise

Normalize Severity

Enrich Alerts

Transform Fields

​How Alert Rules Work

​Viewing Alert Rules

​Creating Alert Rules

​Understanding Conditions

​Condition Logic

​Available Fields

​Condition Operators

​Configuring Actions

​Available Actions

​Multiple Actions

​Priority and Stop Processing

​Rule Priority

​Stop Processing

​Common Use Cases

​Managing Rules

​Editing Rules

​Duplicating Rules

​Activating/Deactivating Rules

​Deleting Rules

​Rule Evaluation Flow

​Best Practices

​Troubleshooting

​Quick Reference

​Condition Operators

​Action Types

​Priority Guidelines

Overview

How Alert Rules Work

Viewing Alert Rules

Creating Alert Rules

Understanding Conditions

Condition Logic

Available Fields

Condition Operators

Configuring Actions

Available Actions

Multiple Actions

Priority and Stop Processing

Rule Priority

Stop Processing

Common Use Cases

Managing Rules

Editing Rules

Duplicating Rules

Activating/Deactivating Rules

Deleting Rules

Rule Evaluation Flow

Best Practices

Troubleshooting

Quick Reference

Condition Operators

Action Types

Priority Guidelines