Build Dashboards

Alert rules

An alert rule watches a number on a dashboard and notifies you when it crosses a limit you set — no need to keep the dashboard open.

Manage alert rules, step by step

List, edit and pause rules on the Alert rules page. New rules are created from a chart.

Alert rules lists every rule you can see, with its condition, who is told and whether it is active. New rules are created from a chart on a dashboard.
Edit rule opens the rule: its name, the metric condition (operator and threshold), the email recipients and how often it is checked.
Pause stops a rule from being checked without deleting it. Resume turns it back on.
To make a new rule, choose Create from dashboard and open a dashboard. Use a chart's menu there to set the condition.

Create an alert

Open the dashboard and find a KPI card with the value you want to watch.
From the card’s Card actions (the three dots), choose Create alert rule.
Give it a Rule name, a Threshold and its Condition, above or below, and, if others in the workspace should hear of it, Notify emails (optional). On a KPI card bound to a governed metric, the rule watches the metric itself, without the page’s filters, and Compares says which of its numbers: see Alerting on governed metrics.
Choose Create alert rule. The rule is checked every 15 minutes and is active immediately; its Evaluation schedule can be changed afterwards in Edit rule.

Creating an alert needs permission to create dashboards (a view-only role does not have it). Alerts are personal — the ones you create notify you.

Create an alert from a card

Open the options menu (the three dots) on a number card and choose Create alert rule. The option appears only for roles that can create dashboards.
Name the alert, choose the Condition and a Threshold, and add the email addresses to notify.
Choose Create alert rule. The rule is saved and appears in the alert rules list, where DataSquares shows when it last ran.
Open Alert rules to see it. Fired alerts show up in Activity and in your notifications.

Alert rules and activity

The Alert rules page lists the rules and what has fired. People without edit rights see it read-only.

Open Alert rules. The summary counts the rules that are Active or Paused and how many have ever fired. Search rules and the filters narrow the list. If your role cannot change rules, the page says View-only access.
Choose Activity to open the notifications page, where fired alerts and their history are listed, newest first.

Notifications

Fired alerts, mentions and system updates arrive on the Notifications page.

Choose the bell at the top of any page, or open Notifications. Alerts, mentions and system updates arrive here, newest first, and the tabs filter them. When nothing has arrived the page says No notifications.

How evaluation works

Alerts are evaluated server-side on a schedule (a background evaluation worker, not your browser), so they fire whether or not you are logged in.

Security & RLS — each evaluation runs under the alert creator’s data permissions, with their role in the workspace’s own company. If the model enforces row-level security, the alert sees exactly the rows you are allowed to see, never more. When its creator leaves the workspace or its company, the alert stops checking: its row on Alert rules says Skipped because the person who created it is no longer in this workspace, and the metric’s owner, or else the workspace’s admins, are told in the app.
Each person’s own number — when an alert fires, each person its email and push reach is told in their own number. Where a row-level security policy binds the alert’s source, each of them is read again as themselves, and told only when their own number is past the threshold, in that number: up to 50 people a firing, within two minutes, and anyone past that is not told. Where no policy binds it, everyone reads the same rows, so the creator’s number is theirs. Nobody who can’t read it is told: an address that belongs to no active member of the workspace, someone who has left, or, for an alert on a governed metric, someone whose role may not open Metrics.
Transition firing — an alert fires on the transition across your threshold: you are notified when the value crosses into the alert condition, avoiding duplicate spam on subsequent checks while it remains past the limit. An alert that compares a period of a governed metric (its latest whole period, or the period so far) is told again by email, push and webhook, and shows again in the bell, once for each new period it compares while it stays past the threshold: a breach that carries from October into November is told for November too, never twice for one period.
What a notice says — the email and the push name the period an alert on a metric compared and write the value and the threshold in the metric’s format: Alert “Revenue under plan” fired — October 2026: 1,180,000 (threshold < 1,190,000). An alert on a field or a log search writes its numbers grouped (1,180,000). The webhook carries the period and the value as written (period, valueText).
Labelled data — an email, a push and a webhook leave DataSquares, so when what an alert reads touches a sensitivity-labelled field, they carry why in the value’s place, whatever the creator’s role: It reads a sensitivity-labelled field that can’t be shown here, so its value is withheld. Someone who may not read the field is not told. The bell stays inside DataSquares, so it shows each person told their number.
Skipped and failed checks — a check whose metric reads no number (nothing in its window, a source the alert’s creator cannot read, a read that ran out of time) does not fire, and the next check waits for the schedule. Its row on Alert rules says Skipped and why, or Failed when the check stopped on an error, under the time it was last checked.

Notification channels

Channel	What you get
In-app	The bell icon and the Notifications page — newest first, each firing with the rule’s name, when it fired and a direct link to the dashboard, for the alert’s creator and everyone who may view the workspace’s dashboards or its dashboard. It shows the number the alert told you (Metric hit 1180000 (threshold 1190000)): your own where row-level security binds its data, and for the alert’s creator the number it read. Anyone else sees only that it fired (Alert fired), with no number. An alert on a governed metric is listed only for admins and roles with the Metrics view permission, in the list and in the unread count. Supports mark read / Mark all read.
Email	A notification message with the period an alert on a metric compared (Period), the Metric value and the Threshold, and Review alert rules, a link to the rules. It goes to the addresses on the rule that belong to active members of the workspace, each in their own number; any other address gets nothing. A rule names members only: one that names any other address isn’t saved, and someone who later leaves the workspace or its company stops getting it.
Push	A notification on the DataSquares mobile app, for everyone the alert is for: its creator, the workspace members its email names, and the people who have its metric in their favorites and can see dashboards, each in their own number. Each person turns alert push on in the app; a snooze silences it for them.
Webhooks	An `alert.fired` event sent to any configured endpoint — including Slack-compatible webhook formats — when the alert’s creator administers the workspace; see Webhooks.

Managing alerts

Notifications history — past alert firing events and history are visible on the Notifications page.
Editing and deleting — on Alert rules, Edit rule changes a rule’s name, description, Evaluation schedule, condition and Email recipients (and, for a rule on a metric, what it Compares), and Delete rule removes it; or use the Alerts API (GET, PUT, DELETE /api/dashboard-alerts/{id}).
Snooze for me — on Alerts, the bell-off menu on any rule you can see quiets it for you for an hour, eight hours, a day or a week. While it is snoozed you get no email or push from it and its firings don’t count as unread for you; it keeps firing for everyone else, and the rule’s owner can still pause it for everyone. Notify me again now ends the snooze early.
Read one at a time — opening a notification marks that one item read and leaves the rest; Mark all read still clears everything at once.

Alerting on governed metrics

On a KPI card bound to a governed metric, Create alert rule watches the metric itself (Alert on Revenue, a governed metric, checked every 15 minutes.): one rule on the agreed definition, whatever card shows it. Compares says which of its numbers the rule compares with the threshold:

Compares	What it compares
Its latest whole period	The number its card shows: its latest whole day, week, month, quarter or year, once that period is complete. New alerts compare this unless you choose another.
The period so far	The period running now, counted up to now. It starts again at the start of each period.
All of its data	Everything so far, as alerts made before compared. A total only grows, so a “below” alert on it may never fire.

The page’s filters. An alert on a metric reads the metric itself, never the page’s filters, while its KPI card follows those on the metric’s data model. When some of them narrow the card, Create alert rule says so: This alert checks the metric without the page’s filters: it won’t be filtered by Region, as this card is. Set its threshold for the metric’s own number.

Alerts made before. An alert on a metric made before alerts compared a period keeps comparing all of the metric’s data until its owner switches it, and its owner is told once in the app (Alert “…” still compares all of Revenue’s data). Open Edit rule on Alert rules and choose Its latest whole period under Compares; until then the dialog says This alert was made before alerts compared a period, so it compares all of the metric’s data. Choose its latest whole period to compare the number its card shows. Saving the rule without switching it keeps it as it was.

The Alert rules list names what each rule on a metric compares: Revenue (metric), latest whole period < 1,000,000. Through the Alerts API, a metric-bound condition is { metricId, operator, threshold, period }, where period is headline (its latest whole period), period_to_date or all_data; a new alert without one compares headline. A check reads the metric in the workspace’s time zone, as its card does.

You can also ask the AI chat agent to create and monitor metric alerts for you using natural language. It shows the exact condition in an approval card first; the alert exists only once you approve it, and, like any new alert on a metric, it compares the metric’s latest whole period. An alert whose metric is deleted while it is in use is turned off, and says why (Deleting a metric).