Alert rules

An alert rule is the bridge between a monitor target and a channel. Each rule says: when this signal crosses this threshold over this window, fire this severity to this channel.

Anatomy of a rule

  • Operator — one of gt, gte, lt, lte, eq, neq.
  • Threshold — a floating-point number compared against the target's measured value.
  • Window — a duration in seconds. The target is evaluated over the most recent rolling window of this length.
  • Severity — info, warning, or critical. Used for routing, dashboard sorting, and channel formatting.
  • Channel — exactly one. To fan out, create multiple rules or use a webhook channel that distributes downstream.

Idempotency & storm prevention

Once a rule fires, it is suppressed for window_seconds before it can fire again. This is intentional: a rule with a 60-second window evaluating a signal that stays above threshold should not generate one alert per poll for 30 minutes.

If you want faster repeat alerts when a condition persists, shorten the window. If you want slower repeats, lengthen it. There is no separate cooldown setting — the window is the cooldown.

Worked example

Goal: alert me when more than 5 Transfer events happen in any 60-second window on a particular ERC-20.

  1. Add the ERC-20 as a contract. ABI auto-fetches.
  2. Create an event_frequency monitor target and pick Transfer from the event list.
  3. Create an alert rule against that target with operator gt, threshold 5, window 60, severity warning, and your Slack channel.

IMAA polls the contract on your tier's schedule, counts Transfer logs in the trailing 60 seconds, and posts to Slack the first time the count exceeds 5 — then stays quiet for at least 60 seconds before it can fire again.