Rule notifications — get alerted when actions fire

Last updated: May 19, 2026

Rule notifications — get alerted when actions fire

Per-rule settings: notify_on_execution toggle + notify_channels (any of in_app, telegram, email). Notification dispatches when entities_acted > 0 (i.e. the rule actually did something). Payload includes rule name + matched entities (max 20 inline, rest as count) + metrics snapshot. Dispatched via the REALTIME SQS queue (30 max in-flight, 30s visibility, 3 max attempts, 5s base backoff).

Who is this for

Anyone running rules that change live spend. Notifications are the "did something just happen?" channel — paired with execution history (which is the "what happened?" channel).

The settings

In the rule builder (Step 9) or rule edit:

  • notify_on_execution: boolean

  • notify_channels: object with booleans for each channel: {in_app: true, telegram: false, email: true}

Both settings are stored in the automation_rule row.

The three channels

in_app

Always available. Notification shows in the in-app notification center (sidebar bell icon). Live polling means it appears within seconds of dispatch.

No setup needed — works out of the box.

telegram

Requires the workspace's Telegram bot to be connected. See team-116 notifications for setup.

Notification format: short message with rule name + entity count + a link back to /rules/:id.

email

Sent to the user's billing email by default. Configurable per-user via profile settings (separate notification email).

Format: subject Wevion rule fired: [rule name] + body with matched entities + metric values + link.

When notifications fire

Notification fires only when:

  • notify_on_execution = true

  • entities_acted > 0 (the rule actually changed at least one entity)

Notifications do not fire when:

  • Rule evaluated but nothing matched (entities_matched = 0)

  • All matches were skipped (cooldown, daily cap, pending check, entity state conflict)

  • Action is notify_only and nothing matched

For notify_only action + matches > 0: notification fires (because notify is the action).

Dispatch pipeline

After execution:

  1. evaluate-rules.worker.ts finishes; calls notification dispatcher if notify_on_execution + entities_acted > 0

  2. Dispatcher enqueues to REALTIME SQS queue (30 max in-flight, 30s visibility timeout, 3 max attempts, 5s base backoff)

  3. Per-channel notification worker picks up and sends:

    • in_app — writes to in-app notifications store

    • telegram — Telegram bot API call

    • email — email provider API call (SES / Resend / etc.)

Real-time properties: latency typically under 30 seconds end-to-end. Failure on one channel doesn't block others.

Payload contents

Notification payload includes:

  • Rule name + ID

  • Execution start / end times

  • Counts: entities_evaluated / matched / acted / skipped / errored

  • Matched entities (first 20 inline by name + id + metric values + action applied; remainder summarized as "+N more")

  • Link back to /rules/:id + the specific execution entry

  • Metric snapshot used for the evaluation

Use cases

Daily monitoring

notify_on_execution: true + email + in_app channels. Standard for any production rule. You see what happened without polling the dashboard.

Critical rule (extra eyes)

Important rule (e.g. high-budget scale): also add telegram for instant ping on phone.

notify_only (alerting only)

Rule with action = notify_only. Notifications are the entire output. Used when:

  • Learning a new rule's behavior before letting it act

  • Reporting / alerting on metrics without changing state

  • Compliance: notify when threshold reached, even if action requires manual approval

Quieting notifications

If a rule fires too often + notifications become noisy:

  • Raise thresholds (rule fires less)

  • Lower notify_channels (e.g. drop email, keep in_app only)

  • Or accept the noise as signal of an over-tuned rule and adjust

Don't blanket-disable notify_on_execution — you'll lose visibility into automation behavior.

Channel-specific caveats

telegram

  • Requires bot connected at workspace level

  • Per-user subscription via Telegram chat (covered in team-116)

  • Falls back silently if bot disconnected; check Telegram setup if expecting alerts

email

  • Goes to spam if domain isn't allowlisted at the recipient mail server

  • Allowlist noreply@wevion.ai in your email provider

  • Email may be delayed by recipient's spam filter (out of Wevion's control)

in_app

  • Visible only when logged in to Wevion

  • Cleared on read; check before clearing if you need to reference

Common mistakes

  • notify_on_execution: false on production rules — you're flying blind on automation

  • All three channels enabled for every rule — noisy; pick channels based on rule criticality

  • Expecting notifications on skipped matches — only fires when entities_acted > 0

  • Telegram bot not connected — settings show telegram on, but no messages arrive

Related