Alert Rules

Get notified the moment a single ingested event for one of your signals crosses a threshold you define — for example, a refund amount over $200, or a queue depth that drops to zero. Alert Rules are simple, per-event comparisons; there's no aggregation or time-window support (e.g. "average over 5 minutes") today, by design — see How it works.

How it works

Each rule watches one signal and compares every event ingested for it against a threshold, using one of five comparators: =, >, <, >=, <=. The comparison happens against each event individually as it's ingested — a rule for refund_amount > 200 fires the instant a single refund event over $200 arrives, not on a rolling average or a count over time.

Creating a rule

From a workspace's Alert Rules page, click New rule. A rule always targets a signal, so at least one signal must exist in the workspace first. A rule has:

• Name — shown in the bell icon and notifications, e.g. "Refund over $200".
• Signal — which signal's ingested events this rule evaluates.
• Condition — a comparator and a threshold value, e.g. > 200.
• Cooldown between notifications — how many minutes must pass before this rule notifies again after firing (default 60). This only throttles webhook/email delivery — every matching event still updates the rule's fired state and occurrence count regardless of cooldown; see Firing and acknowledgment.
• Tag filters (optional) — only match events whose tags also satisfy these filters, e.g. region = us. Multiple filters on the same tag key are OR'd together (matches any of them); filters on different keys are AND'd (all must match). Leave empty to match every event for the signal, regardless of its tags.

Firing and acknowledgment

A rule keeps a single fired-state row, not one row per matching event — a burst of matching events increments an occurrence count on that one row rather than creating a flood of separate alerts. The bell icon in the top navigation shows every currently unacknowledged rule across the workspace, with that count and a relative "fired X ago" timestamp.

Acknowledging an alert (from the bell icon or the Alert Rules page) is shared across the workspace, not per-user — acknowledging it resets the occurrence count and clears the fired state for everyone. If the rule fires again after that, it's treated as a fresh breach. Because there are no real-time push updates, other workspace members may briefly still see the previous fired state until they reload or their next automatic refresh (every 30 seconds).

Notifications

Independently of the fired state above, a rule can notify over two channels, both optional:

• Webhook — an HTTP POST with a JSON payload describing the rule, the condition, the observed value, and the current occurrence count.
• Email — sent via your organization's own SMTP configuration; see Email delivery (SMTP) below. Defaults to the email address of whoever created the rule, but can be overridden per rule.

Both are gated by the rule's cooldown, so a rule that keeps firing won't spam either channel. Delivery is best-effort — a broken webhook endpoint or a misconfigured SMTP relay never blocks evaluation or ingestion. If the last delivery attempt for a channel failed, the Alert Rules page and the alert's detail view show what went wrong (with a plain-language explanation for common causes like a TLS/port mismatch or a failed login) rather than failing silently.

Webhook payload

{
  "alertRuleId": "8f2c1e3a-...",
  "name": "Refund over $200",
  "workspaceId": "3b7a9d21-...",
  "signalId": "1a4f8c02-...",
  "comparator": ">",
  "threshold": 200,
  "observedValue": 237,
  "occurrenceCount": 3,
  "firedAt": "2026-09-24T21:12:43.000Z"
}

Email delivery (SMTP)

Datius doesn't operate its own outbound mail relay — email notifications are sent through your own SMTP server, configured once per organization by an Org Admin under Settings → Alert Email (SMTP). This requires the Pro or Enterprise plan; see Plan limits.

The Connect with TLS immediately toggle is the part most often set incorrectly: turn it on for port 465 (implicit TLS — the connection is encrypted from the first byte), and off for port 587 (STARTTLS — the connection starts unencrypted and is upgraded automatically once connected). Setting this the wrong way round for your port is the most common cause of a TLS handshake error. If your provider requires two-factor authentication on the account (Gmail, Yahoo, and Microsoft 365 all do), you'll also need an app-specific password rather than the account's normal login password.

Once configured and saved, use the Send test email button on the same page to verify delivery end-to-end — it uses the exact same connection logic as a real alert notification, so a successful test means alert emails will deliver too.

Plan limits

• Community — up to 3 alert rules per workspace; custom SMTP email is not available (webhooks still work).
• Pro — up to 15 alert rules per workspace; custom SMTP email available.
• Enterprise — unlimited alert rules per workspace; custom SMTP email available.

Permissions

Creating, editing, deleting, and acknowledging alert rules requires roles/workspace.owner or roles/workspace.editor in the workspace — the same roles that can manage signals. See Core Concepts for the full role hierarchy.

Try it

Create a rule from a workspace's Alert Rules page, then use the Payload Tester on the signal's page (or a real ingested event) to trip it and see the bell icon and notifications in action.