Conditions

Route: /policies (Conditions step of the policy wizard)

Conditions define which alerts a policy may modify. The visual builder is the same component used in notification rules and workflows.

See also: Overview · Creating a policy · Modifiers and tools

Alert filters

Builder controls

Control	Description
Group Root	Top-level group for all conditions
Add Filter	Add a condition on an alert field
Add Group	Nest a sub-group for AND/OR logic
AND / OR	Combines siblings in a group (shown with two or more items)
Delete Group	Remove a nested group
Maximum depth reached	Nesting limit (five levels)

Drag conditions by the grip handle to reorder. Empty conditions mean no attribute filtering — the policy applies to all alerts allowed by the trigger and time window (see No conditions = every alert).

Ambiguous conditions

Mixing AND and OR at the same level without nesting fails validation: "Ambiguous condition: mixing AND/OR in the same group. Please add groups to disambiguate."

Filterable alert fields

Field names appear in camelCase (same names as %fieldName% in notification templates).

Field	What it matches
severity	Current severity
status	Alert status (open, ack, closed, …)
environment	Deployment environment
resource	Affected system or component
event	Event type
service	Service list on the alert
group	Logical grouping
tags	Alert tags
attributes	Custom metadata — enter the key after selecting the field
origin	Source system
type	Alert classification
text	Description text
value	Metric value as sent by the source (97%, 1.5 GB, 12ms). Accepts numeric comparisons — see Numeric comparisons on text values
createTime / updateTime / lastReceiveTime	Timestamps. Accept relative dates such as now-1d — see Relative time
openFor (Open for)	Computed: how long the alert has existed (now − createTime), as a duration such as 30m, 2h, 1d, 1w
silentFor (Silent for)	Computed: time since the alert was last received (now − lastReceiveTime), same duration values
previousSeverity	Severity before last change
user	User who last modified the alert

Additional fields include correlate, duplicateCount, repeat, rawData, sourceId, timeout, and others.

Operators

Available operators depend on field type:

Operator	Typical use
Equals / Not equals	Exact match
Is in / Is not in	Match any of several values
Contains / Does not contain	Substring or list membership
Greater than / Less than (and or equal)	Numbers, dates (absolute or relative), durations (Open for / Silent for), and the number inside text values (value, attributes)
Regular expression / Not regular expression	Pattern match (case-sensitive or insensitive)

For attributes, all operators are available once you specify the attribute key.

Numeric comparisons on text values

value and every custom attribute are stored as text, but monitoring systems put numbers in them (97%, 1.5 GB, 12ms). With Greater than, Less than, Greater than or equal, and Less than or equal on value or on an attributes key, the server compares the first number found in the text on both sides:

Alert value	Compared as
97%	97
1.5 GB	1.5
12ms	12
3,2 s	3.2 (a comma decimal is accepted)
n/a, high, empty	No number — the condition never matches

The number you type in the condition is read the same way, so value Greater than 80% and value Greater than 80 are the same condition. Units are not converted: 1.5 GB is compared as 1.5, not as bytes. Equals and Not equals stay exact text comparisons (97% is not equal to 97).

Other text columns (resource, event, text, …) do not offer the numeric operators. The same comparison is available in TQL (value:gt:97, attributes.usage:gte:80 — see TQL search and filters) and in the filter builder of views and notification rules; policies with trigger On alert creation and any change type evaluate it on the incoming alert before it is stored.

Example — raise severity when a percentage crosses a threshold:

• Conditions: event Equals → Low disk space AND value Greater than → 80%
• Modifiers: severity set → critical

Relative time

Two kinds of conditions depend on the current time. Both are evaluated when the query runs, so a scheduled policy re-evaluates them on every run and an alert that did not qualify at 09:00 can qualify at 09:30.

Durations — Open for and Silent for. The computed fields openFor (now − createTime) and silentFor (now − lastReceiveTime) take Equals, Not equals, Greater than, Less than, and the or equal variants. Type the duration with a unit — 30m, 2h, 1d, 1w (s, m, h, d, w; decimals such as 1.5h are allowed) — or as plain seconds (3600). Examples: openFor Greater than 1d (alerts older than a day), silentFor Greater than or equal 2h (nothing received for two hours).

Relative dates. Any date column (createTime, lastReceiveTime, updateTime, …) accepts now, now-<n><unit>, or now+<n><unit> instead of a fixed date — for example createTime Less than now-1d, or lastReceiveTime Greater than now-30m. In the builder, turn on the Relative switch next to the date picker to type the expression. A fixed date remains a fixed date: createTime Less than 2025-01-01 never changes meaning.

The same fields and values work in TQL (openFor:gt:1d, createTime:lt:now-1d — see TQL search and filters) and in the filter builder of views and notification rules. On policies with trigger On alert creation and any change type, the values are computed for the incoming alert at that moment.

Builder and TQL

The Conditions step has a Builder / TQL switch above the conditions. Both write the same thing: the policy is always stored as builder conditions, and the TQL is converted when you switch mode, click Next, or save. Hint under the TQL field: "The policy is still stored as builder conditions: the TQL is converted when you switch mode, continue or save."

• Builder — the visual builder described in Alert filters.
• TQL — type the conditions as a TQL query, with the same autocomplete as the alert search. Example: severity:eq:critical AND environment:eq:production. Use parentheses to combine AND and OR: (severity:eq:critical OR severity:eq:major) AND environment:eq:Production.

A TQL query is accepted only if it converts to conditions without changing its meaning. Otherwise the error is shown under the field, and you can neither switch back to Builder nor continue to Actions until it is fixed:

Message	Cause
Incomplete TQL near "…": every filter needs field:operator:value.	A filter without operator or value, or a query ending in AND, OR, or (
Unknown field "…".	The field is not an alert column (custom attributes are written attributes.<key> and are always accepted)
Unknown operator "…".	The operator is not one of the TQL operators
This TQL cannot be stored as conditions without changing its meaning. Use parentheses when mixing AND and OR.	For example a AND b OR c without parentheses

Switching from Builder to TQL can be refused as well:

• Complete or remove the unfinished conditions before switching to TQL. — a filter in the builder is incomplete.
• These conditions cannot be written as TQL (for example NOT groups). Keep editing them in the builder. — the builder conditions have no exact TQL equivalent.

Removing all the TQL text means no conditions (see below).

Matching alerts

Next to the conditions, the Matching alerts panel ("Open alerts that currently meet the conditions.") shows how many open alerts the conditions select right now — No matching alerts, 1 matching alert, N matching alerts — and a table with a sample of them (Resource, Event, Environment, Severity, Status, Text). The panel refreshes a moment after each change, in the builder or in the TQL.

• Only open alerts are counted: closed, expired, and deleted alerts never appear.
• The table shows up to 50 alerts, the most recently updated first; when more match, it says Showing the first 50 of N alerts.
• While a filter is incomplete, the panel waits: "Complete the conditions to see the matching alerts." (or "Fix the TQL to see the matching alerts.").
• For a scheduled policy, these are the alerts the next run would process (time-based conditions such as Open for are evaluated now). For On alert creation and any change type, the panel shows existing alerts that meet the conditions — the same filter will be applied to each incoming alert.

The panel uses the preview API; it does not change any alert.

No conditions = every alert

When there are no conditions, the wizard shows This policy has no conditions: an on-receive policy will be applied to every incoming alert, and a scheduled one to all open alerts on every run. Add at least one condition unless that is what you want.

Example scenarios

Downgrade staging critical alerts

Group Root [AND]
  ├─ environment Equals Staging
  └─ severity Equals critical

Modifiers (on the Actions step): severity set → major.

Tag open alerts from a specific origin

Group Root [AND]
  ├─ status Is in open, ack
  └─ origin Equals prometheus

Modifier: tags add → reviewed-by-policy.

Scheduled cleanup of old open alerts

• General: trigger Daily at fixed time → 02:00, All Day (the default)
• Conditions: status Equals → open AND openFor Greater than → 7d
• Modifiers: status set → closed

createTime Less than → now-7d (with the Relative switch on) is the same condition written on the date column. Because both are evaluated on every run, the policy keeps closing alerts as they age; a fixed date would only match once.

Escalate alerts that stay minor

• General: trigger Every x minutes → 30
• Conditions: severity Equals → minor AND openFor Greater than → 1d
• Modifiers: either status set → closed, or Severity step with Step +1 and Never above critical (see Severity step)

With Severity step, an alert that is still open after a day goes minor → major on the first run that matches. Once it is major it no longer matches severity Equals minor, so the policy does not keep raising it; a condition such as severity Is in → minor, major would take it to critical and then stop at the cap.

Composite OR logic

For (severity = critical OR severity = major) AND environment = Production:

Group Root [AND]
  ├─ Group [OR]
  │    ├─ severity Equals critical
  │    └─ severity Equals major
  └─ environment Equals Production

Best practices

• Start with environment, severity, status, and service before exotic fields.
• Use nested groups for OR-then-AND logic; never mix operators at one level.
• For scheduled policies, combine status with Open for / Silent for or a relative date (now-1d) so batch runs do not touch unrelated alerts and the condition stays valid run after run.
• Compare value and attributes with Greater than / Less than only when the source puts a number in them; a value without a number never matches, so pair the condition with an event filter.
• Watch Matching alerts while editing: the count should be the set of alerts you expect, not most of the dashboard.
• Write simple conditions in TQL if that is faster, and switch to Builder to review the result before continuing.
• After saving, use Run on Creating a policy and verify Alerts Matched.