Rules

An alert rule watches a set of resources for a specific problem and raises an incident when its condition is breached. A rule is a scope (what it watches), a trigger (what kind of problem), a condition (the threshold), a severity, and the channels to notify.

Prerequisites

• At least one channel to notify
• The alerting.write permission to create or edit rules (alerting.read to view them)

Creating a Rule

Navigate to Alerts → Rules and add a rule.

1. Name the rule.
2. Scope — choose the resource type to watch. Choose Any resource to watch all types, or a specific type (Sync, Journey, Loader, Store feed, Identity graph, Trait, Event forwarding, or Contract). For a specific type you can either watch every resource of that type (leave the resource list empty) or list specific resources.
3. Trigger — choose what kind of problem to watch for (see the trigger types below).
4. Condition — fill in the threshold fields for the chosen trigger.
5. Severity — set Critical or Warning.
6. Channels — select one or more channels to notify.
7. Save.

Trigger Types

Each trigger watches for a different class of problem and has its own condition fields.

Fatal error

Fires whenever a scoped resource’s run fails or is detected as a stalled (zombie) run. No additional configuration.

Failure streak

Fires once a resource has failed a given number of times in a row.

• Consecutive failures threshold — for example, 3 fires after three consecutive failures.

Run duration

Fires when a run takes longer than a threshold.

• Maximum duration (ms) — for example, 300000 (five minutes).

Row count drop

Fires when a completed run writes fewer than the expected number of rows — useful for catching upstream data that has silently dried up.

• Minimum expected rows — for example, 1000.

Rejected rows

Fires when too many rows are rejected in a run. Choose one of two threshold types:

• Absolute count — fire when at least this many rows are rejected.
• Percent of total rows — fire when rejected rows exceed this percentage of total rows.

Throughput stall

Fires when fewer than the expected number of successful runs complete within a rolling window — useful for catching a pipeline that has quietly stopped running.

• Window (hours) — the rolling window to evaluate.
• Minimum successful runs — fire when fewer than this many successful runs complete in the window.

Delivery failure

Fires when at least a given number of event deliveries fail within a window.

• Minimum occurrences and Window (minutes).

Contract violation

Fires when at least a given number of contract violations occur within a window.

• Minimum occurrences and Window (minutes).

Severity

Each rule raises incidents at one of two severities:

• Critical — a serious problem needing prompt attention.
• Warning — a lower-priority signal.

Severity is carried onto every incident the rule raises and shown in the incident list.

Scope Tips

• Use Any resource for a catch-all rule (for example, a critical fatal-error rule across the whole workspace).
• Scope to a specific resource type and leave the resource list empty to watch every resource of that type.
• List specific resources when only a few pipelines are critical enough to alert on.

Next Steps

• Channels — Set up where notifications go
• Incidents — See what your rules have raised