Esta página aún no está disponible en español. Estamos trabajando en su traducción. Si tienes alguna pregunta o comentario sobre nuestro actual proyecto de traducción, no dudes en ponerte en contacto con nosotros.
Overview
Monitor notification rules are predefined sets of conditions that automate the process of alerting your team based on tags and rule logic. Instead of individually configuring recipients for every monitor, notification rules let you define once and automatically route all monitor notifications whose notification tagset matches the rule’s scope.
There is a default limit of 1000 rules per organization..
Add the required tags for a monitor notification to be routed to this rule. Matching evaluates the notification tagset. Learn more in How matching works.
Monitors created or updated after the notification rule is saved are routed to the defined recipients if it matches the scope of the rule.
Rule scope syntax
The Notification Rule scope query supports Boolean logic and follows the event-based search syntax supported by many other platform products.
Syntax Element
Description
Boolean operators
Supported: AND, OR, NOT Implicit operator: AND
Wildcards
Only key:* is supported (for example, env:*). Partial wildcards like env:prod-* are not supported. key:* matches if the key exists anywhere in the notification tagset.
Multiple values for the same key
Use either env:(prod OR staging) or env:prod OR env:staging.
Quoting
Wrap values that contain spaces or special characters in quotes, for example: team:"data platform".
Scope examples
Notification Rule scope
Explanation
service:web-store
Route any notification about the web-store service.
service:web-store AND env:prod
Route any notification about the web-store service running on the prod environment.
service:webstore AND NOT env:staging
Route any notification about the web-store service that is not running on the staging environment.
env:*
Route any notification that carry the env:<value> tag (either from monitor tags or group).
Rule scope limitations
The following are not supported:
Keyless tags, such as prod AND service:(A or B) or prod, aren’t supported. Tags need to have a key, in this case for example env:prod.
Partial wildcards (service:web-*) and question mark wildcards service:auth? are not supported. Wildcard is allowed only if used alone like service:*.
Scope length up to 3000 characters.
Configure the recipients
Specify which recipients to notify when a monitor notification matches the rule’s scope. You can always notify all recipients, or set conditional recipients that are only notified when certain conditions are met (for example, route critical alerts to your on-call recipient, and send warnings to a Slack channel).
Notifications can be sent to email or any integration channel. There is a limit of 50 notification recipients per rule. For more information, see Notifications.
Managing notification rules
From Monitor Settings
The Monitor Notification Rules page displays a table of all your notification rules with the following columns:
Name: Notification rule name
Scope: Shows the tag combinations that define when this rule applies (for example, team:shopist service:web-store env:prod).
Team: Lists the teams that this notification rule is associated with (available only when the team tag is added in the scope)
Coverage: Shows the number of monitors that match this rule’s scopes. Use this to verify rule coverage and identify rules that need adjustment.
Notifies: Lists the notification channels (such as Slack or email) that will receive alerts when this rule matches.
Additionally, you can click the vertical three-dot menu on the notification rule to Edit or Delete.
From an individual monitor
In your monitor configuration, the Recipient Summary shows recipients that are applied to the monitor by matching notification rules. On the Monitor edit page, you may also see rules that could match when new groups report (multi alert monitors). The Monitor status page shows rules that match.
How matching works
Notification tagset is the union of monitor tags and tags of the firing group (for multi alert monitors). If a key has multiple values across monitor/group, all values are considered.
Currently matches: A rule matches if at least one reporting group, combined with monitor tags, satisfies the scope; or, if the monitor tags alone do. NOT is evaluated per candidate tagset, so a group with a denied value does not match.
Could match when new groups report (multi alert monitors, Monitor edit surface): Treat each group-by key as present with any value, constrained by the monitor query’s allow/deny filters.
If multiple rules match a single notification, recipients from all matching rules are merged and de-duplicated.
Example: Notification Rule Matching
The following table demonstrates how monitors with different tag combinations match notification rules and their resulting notifications. This table shows how:
Multiple notification rules can match a single monitor notification based on its tags.
The AND logic works for multiple tags within a rule.
All matching notification rules contribute their recipients to the final notification list.
Recipients are deduplicated in the final notification list.
