Alerts

An alert is a query Teramot runs on its own and emails (or posts to Slack) when the result is worth telling. Anyone in the project can see the alerts and their history; creating, editing, testing and pausing them needs the Analyst role, and removing one needs Admin.

Where: Operations → Alerts in the sidebar, with a project open.

The three modes

• Digest sends the result at a set time, for example every weekday morning, changed or not. A digest can show several tables, each from its own query.
• Incident sends only rows that are new, identified by the key columns you pick, or that come back after a waiting period. It can also tell you when a row stops appearing.
• Threshold watches the first value of the first row against a line, with a streak before the state changes, and can tell you when the value goes back.

An alert runs on a schedule or when a table it reads finishes refreshing. A digest always runs on a schedule. Your plan can limit how many alerts a workspace has and how often each one is checked.

Alerts and refreshes

An alert reads the project’s tables as the last finished refresh left them, so it only sees new data after a refresh. The top of the Alerts page shows the project’s automatic refresh (Cron Refresh): when it runs, or that it is paused or not configured. Click it to see every refresh configured for the project, including one-off refreshes still to come, and a link to the schedule if your role can see it. Automatic and one-off refreshes cover the whole project and reload its sources one after another.

• An alert on a schedule checks whatever the last refresh left. Schedule it with some margin after the refresh, which takes a while to finish: if it runs earlier it reads the previous data, so a digest goes out with it and an incident or threshold finds nothing new.
• An alert that runs when its tables refresh runs as soon as a refresh of a table it reads finishes, automatic or manual. If it reads tables from several sources, it can run once per source, as each one finishes.
• A manual refresh of a source, or of some of its tables, also brings in new data if there is any, and can fire alerts: the ones that read those tables run at once, and scheduled ones see it at their next check.
• With no automatic refresh, or with it paused, data only changes when someone refreshes a source by hand, and alerts keep checking the same data until then.

Create or edit an alert

Click New alert, or Edit in an alert’s menu. The form has two tabs:

• Rule — the name, the mode, when it runs, and the query. Say when it runs in your own words (“weekdays at 9:30”, “every Monday at 10”, “the 1st of each month at 7”, “every 6 hours”) or pick a cadence, a time and a timezone; a cron expression is there under Edit as cron if you prefer it. The query is a read-only query over the project’s tables, and what it returns is what the message shows. The fields that follow depend on the mode: the operator, threshold and streak; the key columns and waiting period; or the digest’s extra tables.
• Delivery — who receives it (email addresses, a Slack webhook, or both), the subject, language and layout, your own words around the table, and whether the result travels as a CSV. Recipients do not need a Teramot account. A saved Slack webhook is never shown again: leave the field blank to keep it, paste a new one to replace it, or turn on Remove the saved webhook.

Dry run runs the query and shows whether the alert would fire, how many rows it found and a sample, without saving or sending anything. Save with Create alert or Save changes.

When a saved alert starts sending to an email address that is not a member of the workspace, or to a Slack webhook, the workspace’s owner and admins get an email saying who changed it and where it now sends. It never carries the alert’s results. Sending outside the workspace is allowed; the email is there so that nobody does it unseen.

Run, pause and remove

Each alert’s menu has:

• History — every check: when it ran, what triggered it, whether it fired, how many rows it found, and for each recipient whether the message was sent, failed, or was not sent and why (for example, nothing new to report, or still in its waiting period).
• Dry run — the same test as in the form, on the saved alert.
• Run now — checks the alert for real, records the result and sends what the mode decides.
• Pause / Resume — a paused alert keeps its history and recipients but is not checked.
• Remove — stops the alert for good; its history is kept.

Stop receiving alert emails

Every alert email says at the bottom how to stop it, and mail clients that support it show their own Unsubscribe next to the sender. A Teramot user gets a link that turns these emails off for their account. Anyone else asks a workspace admin to take them off the alert’s recipients, or uses the mail client’s Unsubscribe, which writes to Teramot.

The same alerts can be created and changed from an AI assistant — see Alerts in the tools reference.