Write advanced conditions for filtering alerts using ASQ

Advanced conditions let you decide when a rule or policy applies by writing a query, instead of picking conditions from dropdowns. Unlike in basic, in the advanced editor, you can combine AND, OR, and NOT, and group conditions with parentheses to define complex conditions. That means one rule can handle logic that would otherwise need several.

Advanced conditions use the same syntax as alert search, with a few differences. This page lists the fields, operators, and limits you can use, and explains how a condition differs from a search.

Where you can use advanced conditions

Alert policies, notification policies, alert group notification policies, routing rules, user notification preferences and rules, and role-based notification rules.

Switch to the advanced editor

1. Open the rule or policy you want to edit, or create a new one.

2. In the alert filters section, switch from Basic to Advanced.

3. Enter your query. When you select outside the field, we validate the query and show any errors.

4. [保存] を選択します。

Rules you've already built in the basic editor keep working as they are.

フィールド参照

Use field:value with the fields below. Field names are case-sensitive: write message, not Message.

Fields that only exist later in an alert's life, such as count, status or createdAt, can't be used. A condition runs when you create the alert, before those values exist.

On AI notification policies

An AI notification policy matches a group of alerts, not one alert. A group has four fields, and only these can be used:

条件演算子

> and < work on priority only. >= and <= are not supported; the error tells you what to write instead. For example, priority >= P3 becomes priority > P4.

Quoting values

Quote a value when it contains a space or any of : ( ) < > = ! \, or when it starts with an asterisk. Single and double quotes both work.

Also quote a value that is a keyword: true, false, and, or, not or is. For example, message:"true".

A value cannot be empty: source:"" is rejected.

論理演算子

Group values for one field with parentheses:

Combine conditions with AND, OR and NOT:

• Mixing AND and OR needs parentheses. priority:P1 AND tags:prod OR source:web01 is rejected, because it can be misread. Add parentheses to say which you mean. The same applies inside a field group.

• Join every pair of conditions. source:web01 tags:prod is rejected. Write source:web01 AND tags:prod.

• Write AND, OR and NOT in upper or lower case. and works; And does not.

• To exclude a list of values, put NOT in front. NOT tags:(prod OR canary) matches alerts with neither tag. tags!:(prod OR canary) means "missing prod, or missing canary", which matches almost every alert.

• Where the field is not set, NOT also matches alerts. To exclude web01 only among alerts that have a source, write source is not null AND NOT source:web01.

アスタリスク (*) をワイルドカードとして使用

In a condition, a value without an asterisk must match the whole field. This is the biggest difference from alert search, which matches single words.

例

message:outage matches only a message that is exactly "outage". To find the word inside a longer message, write message:"*outage*".

• An asterisk only goes at the start or the end. source:"web*01" and source:"*" are rejected.

• No wildcards on tags, actions, responders, priority or snrClassification. These must match a whole entry: tags:prod does not match a tag called production.

• In details.key and details.value, an asterisk is a normal character. details.key:run* looks for a key named exactly run*.

• In detailsPair, the value takes wildcards and the key does not. detailsPair(region:AP*) works; detailsPair(reg*:APAC) is rejected.

Null queries

A null query matches alerts where a field is set, or is not set. A field counts as null if it is not set or is blank.

Supported fields: source, entity, tags, actions, responders.

Null queries are rejected on message, alias, description, priority, snrClassification and the details fields. To match the word null as text, quote it: source:"null".

Where you can use it

Alert policies, notification policies, alert group notification policies, routing rules, user notification preferences and role-based notification rules.

Not on integration create-alert rules or sync. Those keep the basic editor.

制限

Extra parentheses, and repeating the same operator as in a AND b AND c, add no depth.

There is also a fixed limit on how many rules can use an advanced condition. Existing advanced rules can always be edited, even at the limit.

What gets rejected

Nothing invalid is saved. The error shows where in the query the problem is, and a reason code.

Going over the advanced-rule limit is a separate error with no reason code, for example "You can not have more than 1000 advanced query routing rules."

Behavior worth knowing

• Matching ignores case. source:WEB01 matches web01.

• P1 is the highest priority. priority > P3 returns P1 and P2.

• A query is saved exactly as typed. Each condition you write counts once toward the limit of 50.

• Existing rules keep working unchanged. A rule built in the basic editor behaves as before and opens in the basic editor.

Basic and advanced editors: how conditions map

Switching editors rewrites the same rule in the other form. Nothing changes until you save, and a rule that cannot be switched keeps working as it is.

What each basic condition becomes

Values are quoted for you when the query needs it.

What stays in the basic editor

A rule stays in the basic editor if any of its conditions has no query form:

Advanced back to basic

The same mapping applies in reverse. A query can go back to the basic editor when it is one condition, or several conditions joined by the same operator: priority:P1 AND tags:prod becomes two rows under Match all conditions.

It stays in the advanced editor if it has:

Differences from alert search

例