Skip to content
Menu

Alerting & tasks

Explore · Alerting & tasks

The right message, to the right channel, only when it matters.

A subscription decides which runs notify anyone, then delivers the result to vetted recipients on five channels. Runs with rows can open a task that stays open until the data is clean, and anomaly detection can replace fixed triggers with a statistical baseline.

  • 5delivery channels
  • 3notification triggers
  • 3anomaly methods
TeamsAdaptive Card
Beacon
Payments DB: Failed card payments
First 10 records · 3 columns
Slack#payments-ops
[Beacon] Payments DB - Failed card payments
Results: Showing 12 of 12 total records
JiraPAY-214
BEACON: Failed card payments
TaskMediumBeacon
WebhookPOST · application/json
{ "source": "Beacon", "totalRecords": 12, "previousResultCount": 0, … }
01Triggers

When does a run notify?

Every run is recorded with a status, and recipients are notified only when it is Sent. A run with no rows ends as No results, whatever the trigger. Pick a trigger to see how the same seven runs play out.

  1. 09:000 rowsNo resultszero rows never notify
  2. 10:003 rowsSent0 → 3, changed
  3. 11:003 rowsSilenced3 → 3, unchanged
  4. 12:005 rowsSent3 → 5, changed
  5. 13:002 rowsSent5 → 2, changed
  6. 14:002 rowsSilenced2 → 2, unchanged
  7. 15:000 rowsNo resultszero rows never notify

3 of 7 runs notify the recipients.

Sent: recipients notifiedSilenced: the trigger did not fireBelow threshold: fewer rows than the minimumNo results: the query returned no rows

A run is compared with the last run that was not skipped. With anomaly detection on, the trigger is not used: after the same checks, a run is Sent only when its row count is unusual (section 04).

02Channels

One run, five formats.

Each channel receives the same run in its own format: a title, the preview rows (at most 20, cut further by the subscription's Max rows and the channel's own limits), and the total row count. Rows are PII-masked before any channel sees them.

TEAMS · ADAPTIVE CARD 1.5via Workflows webhook
Beacon
Payments DB: Failed card payments
First 10 records
payment_idmerchantamount
pay_7Q2K81Northwind Outfitters Ltd129.00
pay_7Q2K64Blue Fern Cafe8.40
pay_7Q2K50Contoso Travel412.75
pay_7Q2K47Acme Hardware56.10
pay_7Q2K33Tailspin Toys34.99
pay_7Q2K29Fabrikam Home and Garden218.00
pay_7Q2K18Litware Books22.50
pay_7Q2K12Adatum Pharmacy17.80
pay_7Q2K09Proseware Fitness49.00
pay_7Q2K05Wingtip Florist64.30
View Query Results
ChannelInline rowsAttachment
TeamsFirst 10 rows, first 3 columnsNone
SlackFirst 25 rows, first 5 columns, each column cut to 20 charactersNone
EmailThe preview rows, as an HTML tableCSV or XLSX
JiraThe preview rows, as a tableNone
WebhookThe preview rows, as JSONNone

Teams, Slack and the webhook link back to the run's notification page when a base URL is set. The SQL is included only with Show query text in notification on. Slack and the webhook also carry anomaly details when detection flagged the run. A webhook recipient can replace the body with its own template.

03Tasks

A task stays open while the problem does.

With Create a task on, the first run with rows opens a task. Later runs update it, and a run with no rows resolves it. Notifications say that something happened; tasks track whether someone dealt with it.

TASK #57Unresolved
Failed card payments
P2 · HighAssignee: Ana Horvat2 watchers
SLA · 4 hours3h 15m left
18latest rows
4executions
3notifications
45mage
R resolve A assign to me S snooze 1 hour C comment

The SLA counts down against the subscription's SLA hours, or 24 hours when none is set; an Admin sets 1 to 720 hours from the task page. Every run that executes the query updates the task, whatever its notification status.

04Anomaly detection

Notify on the unusual, not on every change.

With anomaly detection on, a subscription compares each run's row count with the runs of its lookback window and notifies only when the run is unusual. It is statistical and needs no LLM. Switch the sensitivity to move the threshold.

CHARGEBACKS OPENED TODAY · STANDARD DEVIATION
6101418mean 11.020 baseline runs (lookback 30 days)this run
Silencedz = (14 − 11.00) / 1.14 = 2.63 ≤ 3σ
Anomaly: notifyz = (14 − 11.00) / 1.14 = 2.63 > 2σseverity Medium
Anomaly: notifyz = (14 − 11.00) / 1.14 = 2.63 > 1.5σseverity Medium
SensitivityStd. deviationPercentage change
High1.5σ15%
Medium2σ25%
Low3σ40%

High alerts most often. IQR ignores the sensitivity: its bounds are always 1.5 × IQR beyond Q1 and Q3. Severity follows the size of the deviation (for standard deviation: Medium from 2, High from 3, Critical from 4).

The metric is the row count

Beacon measures how many rows a run returns. Write the query to return one row per item, not a single COUNT(*) row. No run is an anomaly until the lookback window holds the minimum data points (7 by default).

05Worked example

Failed card payments, one morning.

A payments team wants to hear about card failures when they grow, and wants someone to own the problem until it stops. One subscription does both.

Query · Failed card payments (Payments DB, PostgreSQL)
SELECT payment_id, merchant, amount, currency, decline_code, created_at
FROM payments.card_payments
WHERE status = 'failed'
AND created_at > now() - interval '1 hour'
ORDER BY created_at DESC;
NEW SUBSCRIPTIONReview
Cron expression
*/15 * * * * (every 15 minutes)
Send notification
When result count increases
Recipients
Teams, Jira PAY, email ops@acme.example
Tasks
Create a task and keep it open while the query returns rows
Attachment
CSV (email only)
  1. 09:000 rowsNo resultsNothing is sent; no task exists.
  2. 09:1512 rowsSent12 is higher than 0. Teams, Jira (issue PAY-214) and email are notified. Task #57 opens.
  3. 09:3012 rowsSilencedNot higher, so nobody is notified. The task's executions climb.
  4. 09:4515 rowsSentHigher again. Jira gets a comment on PAY-214. Ana Horvat presses A and sets the priority to High.
  5. 10:0018 rowsSentStill growing: three unique counts in four executions.
  6. 10:150 rowsResolvedThe provider recovered. No results, nothing is sent, and the task resolves itself.
06Destinations

Recipients deliver only where they are allowed to.

A recipient is one destination on one channel. Only an Admin or a SecurityAdmin creates or changes one; everyone else attaches existing recipients without seeing where they deliver. Every destination is checked when it is saved and again when Beacon connects.

DESTINATION CHECKdefault policy
TypeDestinationResult
Slackhttps://hooks.slack.com/services/T…/B…/…Allowed
Teamshttps://prod-12.westeurope.logic.azure.com/…Allowed
Teamshttps://outlook.office.com/webhook/…Retired connector
Jiraacme;PAY;bot@acme.example;••••Allowed
Webhookhttp://hooks.acme.example/beaconHTTPS only
Webhookhttps://bot:pw@hooks.acme.example/Credentials in URL
Webhookhttps://10.20.4.12/alertsPrivate network

Vendor hosts

Slack delivers to hooks.slack.com, Teams to *.webhook.office.com, *.logic.azure.com and *.environment.api.powerplatform.com, Jira to *.atlassian.net and api.atlassian.com. A host can extend each list.

No private networks

Private, loopback and link-local addresses are unreachable unless the host lists them. Beacon connects only to an address it checked itself, and never follows redirects.

Encrypted secrets

Destinations and header values are encrypted when saved and shown masked. Webhook headers are limited to an allow-list such as Authorization and X-Api-Key.

Reviewed changes

When the approval workflow is enabled, a new or changed destination receives nothing until a second person approves exactly where it now delivers. Reviewers compare fingerprints, never credentials.