Rules

The Rules tab

Open Organisation Settings → Alerting and switch to the Rules tab. Each row shows:

• Name — click to open and edit.
• Event — the event type the rule listens for.
• Channels — a count of channels the rule dispatches to (e.g. "2 channels").
• Status — Enabled or Disabled. A disabled rule keeps its configuration but doesn't fire.

The row menu (⋮) offers Edit, Delivery history, and Delete. Click Add rule at the top right to create one.

Creating a rule

Every rule has the same skeleton:

• Rule name — required. A label, e.g. "FinTech anomalies → Finance Slack". Helps when you have many rules covering different teams or environments.
• Event type — required. The dialog adapts its scope fields to whichever event type you pick. See Event types.
• Enabled — disable a rule to silence it without deleting it. Useful for maintenance windows, bake-in periods after a noisy launch, or temporary on-call rotations.
• Scope — optional filters that narrow which events match this rule. See Scope filters.
• Delivery channels — required. Pick one or more channels. Channels marked Disabled still appear in the picker but won't actually deliver until re-enabled.

Event types

Anomaly detected

Fired when Cirrova raises a new cost anomaly for a resource. The payload identifies the resource, the resource group, the subscription, the severity, the baseline and current daily averages, and a plain-language description of the change. See Anomaly Detection for how anomalies are computed and what severity means.

Anomaly resolved

Fired when a previously-detected anomaly has resolved — the resource's costs have returned to (or below) baseline. Resolution is automatic; there is no manual close action.

Budget threshold crossed

Fired the moment a budget's spend in the current period crosses one of its configured alert thresholds — 50%, 75%, 90%, or 100%. Each threshold fires at most once per billing period. A budget with thresholds set at 75% and 100% can therefore fire this event up to twice per period. See Budgets → Alert thresholds for how thresholds are configured.

Snapshot failed

Fired when a data collection run fails during post-processing — typically because the post-processing step exceeded its timeout, but any unrecoverable error is reported through this event. Useful as an operational alert; the absence of fresh data is otherwise easy to miss.

Scope filters

Scope fields are filters: leave a field empty to match everything, populate it to narrow the match. Every populated filter must be satisfied for the event to match — filters AND together. The available filters depend on the event type.

Anomaly events (detected and resolved)

• Tenants — only anomalies on resources in the selected tenants match.
• Subscription IDs — one ARM subscription ID per line; only anomalies on resources in those subscriptions match.
• Resource group names — one name per line; case-insensitive match against the resource's resource group.
• Tag filters — one or more tag key/value pairs. The resource must carry every listed tag for the rule to match. Leave a value blank to match any value of that key. The same tagging convention used by Tag Collection budgets and scoped events applies here.

Budget threshold events

• Budgets — only threshold crossings on the selected budgets match. Leave empty to match all budgets in the organisation.

Snapshot failed events

• Tenants — only failures for the selected tenants match.

The "leave empty to match all" pattern lets you start broad and narrow later. A common starting point is one rule per event type with no scope filters, then split into more specific rules as you grow more channels or want different severity treatments per environment.

Multiple matching rules

An event can match more than one rule. If three rules all match an anomaly detected event, every channel referenced by any of those three rules gets a delivery. Cirrova de-duplicates per channel, so the same email channel referenced by multiple matching rules only sends one email per event.

This is useful when you want overlapping audiences: a "production tenant" rule that fires for every prod anomaly, and a "tag=critical" rule that fires regardless of tenant. An anomaly that matches both fires both rules, and a channel referenced by both still receives a single delivery.

Delivery history

From the rules table, the row menu's Delivery history action opens a chronological log of every delivery attempt that rule has triggered. Each row shows the time, the channel that received the delivery, the originating event, the resulting HTTP status (or OK for native channels), and a short detail line — e.g. the response body for non-2xx HTTP results, or the error message for transport failures.

Delivery history is the first place to look when an alert didn't arrive. Common patterns:

• No row at all — the rule didn't match the event. Check the scope filters; the most common cause is a tag filter that's tighter than the resource's actual tags.
• Row present, status non-2xx — the channel rejected the delivery. For webhooks, the status code and a snippet of the response body are recorded; check signature verification on your endpoint.
• Row present, "Channel disabled" — the channel was disabled at delivery time. Re-enable it on the Channels tab.

Webhook deliveries that don't return 2xx are retried automatically — see Custom webhooks → Retry schedule.