Data Alerts — Thresholds & E-mail Alert Rules

Alerts — conditions, suppression and alert rulesSix conditions, four things to watch, and the rules that stop an alert from mailing the same news ninety-six times a day. An alert is a question asked on a schedule — is the total over the limit, did a single trade breach, has September's data arrived, did anything change — and an e-mail only when the answer is worth reading. ATX AnalyticsTable has two places to ask it, and they share one engine. The first is the Send email step inside a pipeline (chapter 17): clean the data, then tell people about it. The second is Transform → Alerts, a list of standalone alert rules that watch a source directly, with no pipeline around them — a SQL query on the project database or a stored connection, a query from the saved-query library, a pipeline's bound data, or a block of cells on a sheet. The condition, the suppression rules, the message templates and the mail transport are the same code in both, so an alert behaves identically wherever it is built and a template can move between a step and a rule unchanged. What makes alerts usable over months rather than days is what happens after the condition is true. By default a rule fires on the rising edge only: it mails when the condition becomes true and stays quiet while it remains true, so a threshold checked every fifteen minutes produces one message, not ninety-six. A cooldown, a daily maximum and an optional recovery message complete the picture. The rule itself is saved in the project and travels with it through Git; what each rule has already told people is remembered on the machine that sent it, so a colleague opening the same project starts with a clean slate rather than silently inheriting somebody else's suppression.

What it does

Six conditions, the same in a pipeline step and a standalone rule: on every run; when the row count crosses a value; when an aggregate crosses a value; when any single row breaches; when data arrives for a new period; when the data changes
Aggregate thresholds over one column with SUM, AVG, MIN, MAX, COUNT and COUNT DISTINCT, compared with >, >=, <, <=, =, != or contains
Any-row alerts that report how many rows breached and carry the first breaching rows into the message — "tell me when a single trade is over the limit"
New-period alerts by day, ISO week, month, quarter or year, read from a date column in local time — "tell me when October's data arrives"
Change alerts by fingerprint over the whole table or only the columns you name, so a reordered extract or an untouched column does not count as news
Standalone alert rules in one list under Transform → Alerts, watching a SQL query (on the project's own DuckDB or a stored connection), a saved query, a pipeline's bound dataset or a range on a sheet — a named range or a plain reference picked on the grid
Suppression: only when it changes (on by default), a cooldown in minutes, a maximum per day (24 by default) and an optional one-off message when the condition recovers
Templated subject and body with run tokens — {{condition}}, {{condition.value}}, {{condition.threshold}}, {{rowCount}}, {{runAt}}, {{runDate}}, {{col:Name}}, {{agg:SUM(Column)}}, {{table}} — and the project's ${parameters}
HTML or plain-text messages, with the table attached as CSV, Excel or HTML
Check now evaluates a rule immediately, suppression included, and shows when it was last checked, what it decided and whether a message went out
Rules are scheduled on the same scheduler as pipelines, refreshes and PDF exports, with the same time zones, retries and run history
An on/off switch per rule: a misfiring alert is switched off, not deleted, and keeps its configuration for the morning
Duplicate a rule to make a variant — the copy starts with no history, so it is not suppressed on its first run by the original's state
Ask Greg can propose an alert rule, tells you whether it would fire right now before you place it, and marks the rule it placed with the question that produced it

How it works

Open Transform → Alerts and press New alert. A new rule starts as "row count > 0" rather than "on every run", because a standalone rule that mails on every tick is a newsletter, not an alert. Give it a name; the list on the left shows every rule in the project with its on/off switch.
What it watches. Choose a source. A SQL query runs on the project's own database (Local DuckDB) or on any stored connection — the same choice a SQL pipeline step offers. A saved query runs the SQL that the query library holds, visual queries included, so the rule cannot drift from what the library would run. A pipeline's data is read from the pipeline's bound dataset without running the recipe: an alert watches data, it does not transform it. A range on a sheet is read either through a named range — preferred, because a name follows its block when rows are inserted above it — or through a reference you type or pick on the grid, such as C1R1:C4R500, with or without a header row. Queries are read up to 10,000 rows.
When it fires. Pick one of the condition types and fill in its column, aggregate, operator and value. Because a standalone rule's source is not read until it runs, there is no live column list to choose from; the column name is typed, and a line underneath reads the condition back in words — "Fires on: SUM(Amount) > 50000".
Blanks are not zeros. Empty cells are left out of every aggregate, so AVG and MIN answer correctly; COUNT counts values, while the row-count condition counts rows. A column with no usable values does not breach a threshold — an empty run never fires "total < 100". Numbers written with spaces as thousands separators and a decimal comma, as a Polish system exports them, are read as numbers.
New period and data changed need a memory, so their first run only learns. A new-period rule notes the newest period already in the data and stays quiet; the next period to appear fires it. A change rule notes the current fingerprint; the next different one fires it. Nobody is mailed, on the day a rule is saved, about data that was already there.
The condition decides whether the data is interesting; suppression decides whether this run sends. With only-when-it-changes on, a condition that was already true at the previous check is reported as "still true since the last run" and not sent. A cooldown refuses a second message within the set number of minutes, and the daily maximum is a hard ceiling per rule per calendar day. With recovery on, one message goes out when a true condition becomes false again. A rule that fires on every run is exempt from the change and cooldown rules — a nightly report must not be silenced after its first night — but not from the daily cap.
Who it tells. A rule sends through a mail profile from Settings → Email (chapter 17) to the addresses in To — comma-separated, where a distribution list or a group mailbox counts as one address. Subject and body accept the run tokens and project parameters; a standalone rule has no pipeline, so {{pipelineName}} resolves to the rule's own name and a template moves between a step and a rule unchanged. The body is HTML or plain text, {{table}} renders the rows inline, and the table can be attached as CSV, Excel or HTML.
Check now evaluates the rule against its source this moment and sends if the decision says so — suppression included, so a check that stays quiet is telling you exactly what a scheduled run would do. It works on a rule that is switched off, so a new alert can be tried before it is trusted to run alone. Schedule… closes the dialog and opens the scheduler with the rule already chosen as the target.
Every check leaves a record on the rule: when it ran, whether the condition was met, the sentence explaining why, whether a message went out, and any error. A source that cannot be read — a deleted pipeline, a missing saved query, a sheet that no longer exists — and a send the mail server rejected are recorded as failed runs in the scheduler, never as an alert that simply did not fire. A scheduled run of a switched-off rule records "Alert … is turned off.", so "it never fires" always has an answer.
Where things are kept. The rule — what to watch, when to fire, whom to tell — is saved in the project file and versioned with it. The alert state — last period seen, last fingerprint, whether the condition held last time, when it last fired and how often today — is kept per rule in a small file in the user profile on the machine that ran it, so it survives restarts and is the one file to delete to make every alert start fresh.

Practices that keep it reliable

Place a new rule switched off, press Check now until the decision line reads the way you expect, then switch it on and schedule it
Leave "Only when it changes" on for any threshold or any-row rule on a short schedule; add a cooldown if the number hovers around the line
Turn on "Also send once when it recovers" for operational alerts, so the people who were told about a breach are also told it is over
Prefer a named range over a typed reference for a sheet source — a name follows its rows when someone inserts lines above the block
Point a rule at a pipeline's data when the numbers need cleaning first, and keep the cleaning in the pipeline; the rule only reads the result
Put the standard footer for every alert in one project parameter and reference it as ${…} in each body, so changing it is one edit
Write subjects that carry the value — "{{pipelineName}}: {{condition.value}}" — so the inbox list answers the question without opening the message
Switch a misfiring rule off rather than deleting it; the configuration is what you will want back once the source is fixed

In a regulated environment

Every alert this installation sends from a standalone rule is in one list, readable by a compliance officer or the next person on call without opening a single pipeline
Rules are project content: they are reviewed and versioned in Git with everything else, and a rule placed by Ask Greg carries a visible Ask Greg tag with the question that produced it
Alert memory is machine-local by design. A project opened on a second machine starts with its own state, so one person's suppression never hides a first alert from another
Conditional sending is its own licence component, email-alerts, separate from email-send (ordinary delivery) and email-read (mailbox reading); an installation can be entitled to alerts without bulk delivery
An optional email-daily limit caps messages per calendar day across every profile, pipeline and rule — a bound on a runaway schedule, not a meter on normal use. Absent means unlimited
Recipient controls are the mail profile's: a maximum per message and an allow-list of recipient domains (chapter 17) apply to alert rules like any other send
Ask Greg's alert proposals are limited to addresses the user typed in the session, the mail profile's own address, or people who already receive an existing alert — never an address found in the data — and the SQL behind an alert source is held to the assistant's SELECT-only contract. Placing one needs ai-agent-actions plus email-alerts, and every placement is written to the audit trail with each recipient and the rule that allowed it
Only e-mail is supported as a delivery channel today; Cc and Bcc, a profile picker and a message preview are on the pipeline's Send email step, not yet in the Alert rules dialog

Screens

Transform → Alerts — every rule in one list, each with its own on/off switch. This one runs a SQL query on the project's own DuckDB and fires when the day's revenue, summed, falls below 150,000.
When it fires — the condition read back in words, then suppression: only when it changes, a 60-minute cooldown, at most four messages a day, and one more when the number recovers.
Who receives it — a mail profile, recipients, a subject and body built from tokens, the table attached as Excel, and Check now to try the rule before it is scheduled.
Watching a pipeline's data for a new month in order_date. The pipeline is read, not run, and the first check only notes the month already there — the next new one sends.
The same conditions inside a pipeline: the Send email step's "When to send" uses the evaluator, suppression and templates an alert rule uses.
Schedule… on a rule opens this scheduler with the rule pre-selected — the same triggers, time zones, retries and run history as pipelines and PDF exports.

ATX Institute on LinkedIn

This site needs JavaScript for the full experience. Every page above is reachable without it.