Alert Rules

The type of subject the rule watches, such as handlers, processors, or Axon Server disks. You choose it when you create the rule and cannot change it afterwards; to watch something else, create a new rule.

Narrow the rule down to the subjects you care about, based on their properties: the application name, the processor name, the message type, and so on. A filter can match a value exactly (equals, not equals), one of a comma-separated list (any of, none of), or a pattern with * as a wildcard (like, not like). Pattern matching ignores case. When you add several filters, a subject must match all of them.

Decides how fired alerts are grouped into inbox items. Left empty, all alerts of the rule in one environment end up in a single inbox item. Choose one or more properties to get a separate item per distinct value—for example, split by application name to get one item per application. Each item is snoozed, archived, and notified about on its own.

What to measure, such as latency, error rate or free disk space. The metrics available depend on the scope; see Subjects and Metrics.

For example > 250 ms. Durations can be entered in milliseconds, seconds, minutes, hours, or days.

For timing metrics, which reading to judge: the minimum, the median, the ninetieth percentile, the ninety-fifth percentile, or the maximum. The ninetieth percentile is a good default: it ignores the occasional outlier but still catches a slow tail.

Critical, Major, Minor or Info. The severity decides the priority of the inbox item and which integrations are notified.

How many minutes a condition must hold before the alert triggers. Until then the alert is pending: you can see it on the rule and on the subject, but no inbox item opens and nobody is notified. This filters out short spikes.

How many minutes the subject must stay healthy before the alert resolves. If the problem returns within that time, the alert simply continues. This prevents a flapping subject from opening and closing the same item over and over.

For message-driven subjects such as handlers, aggregates, and entities, the minimum number of messages per minute before the rule judges a subject. A latency measured over two messages says little; set this to ignore quiet periods. Throughput conditions are always judged.

The rule applies to every environment in the workspace, including environments you create later.

The rule applies only to the environments you select.

Turn a rule off without losing it. A disabled rule is not checked, and its firing alerts resolve.

Every saved change creates a new version. Previous versions lists them with who made the change and when. Select a version to load it into the editor, then save to restore it.

Removes the rule. Inbox items it already opened are kept.

Replaces all rules in the workspace with the default rules. Rules that already match a default are kept, missing defaults are added, and every other rule—including rules you created yourself—is removed. Inbox items are kept.

One row per subject the rule is firing or pending on, with the measured and worst values.

Every inbox item the rule has opened, in any status, and the rule version it opened under.

One row per alert in the last 30 days, from the moment the subject started breaching, through triggering, to recovery.