Act

Webhook automations

A rule watches one template, waits for the change you care about, checks its conditions, and dispatches to the channels you attached. The record that fired it carries the history that explains why.

Four triggers

Every rule binds to a template and picks one of four events.

A record appears

on_entity_created

Fires when a new record is created on the template you bound the rule to.

A record changes

on_entity_updated

Fires on any update to a record of that template, whoever or whatever made it.

One field changes

on_attribute_changed

Narrows the rule to a single attribute, so a status flip fires and an unrelated edit stays quiet.

An action runs

on_action_executed

Fires once per run of a specific Action on the template, whoever or whatever ran it — a hook for “this operation happened,” not just “something changed.”

Ingested metrics run through the same engine

Batched telemetry is evaluated by the same rule engine that handles a manual edit. A reading that crosses a limit reaches a channel on the strength of the ingestion itself, with no polling job standing in between.

Conditions

A rule carries a list of condition expressions evaluated against the record. All of them must pass before any action runs, so a threshold and a status and an owner can be required together.

Where it dispatches

HTTP webhooks

A target URL with your choice of method, custom headers, and bearer or basic authentication. Anything with an inbound URL is reachable: your own service, a serverless function, or a Slack incoming webhook.

A bot token and a destination, for alerts that need to land in a channel an on-call rota already watches.

Mobile push

Registered devices receive the alert directly, for the cases where a phone is the only screen nearby.

Payload templates

The body of a webhook, and the text of a Telegram or push message, are templates rendered against the event. These are the variables it can substitute: automation.id, automation.name, entity.id, entity.template_id, timestamp, plus values.<slug> for a current value and previous.<slug> for the state it replaced. Attribute ids work in the same position, so a template survives a rename either way. A name with no match renders empty.

{
  "alert": "{values.site} moved to {values.status}",
  "record": "{entity.id}",
  "was": "{previous.status}",
  "now": "{values.status}",
  "reading": "{values.coolant_temperature}",
  "rule": "{automation.name}",
  "at": "{timestamp}"
}

Values arrive as a person would read them. A list attribute renders its option label, a reference renders the display name of the record it points at, and a file renders its original filename, so an alert says Drifting where the stored value is an identifier.

Message bodies also accept Markdown, so an alert can carry headings and lists. A test dispatch sends one through the channel before the rule goes live.

Walkthrough: a cold-chain excursion alert

A Site template carries a coolant_temperature metric, ingested every few seconds from a fleet of sensors. One rule watches it, start to finish:

1

A reading arrives

coolant_temperature for Cold Room 3 comes in at 9.4°C, one observation among thousands ingested that minute.
2

The trigger matches

The rule is bound to Site and set to fire on an attribute change to coolant_temperature, so this ingest reaches it.
3

The condition passes

Its one condition, coolant_temperature greater than 8, evaluates true. A reading at 6°C would have stopped here.
4

The channel dispatches

The Telegram channel attached to the rule renders the payload template above and sends it to the on-call chat.
5

The run is recorded

The execution log stores the triggering record, the timestamps, and a success status, so anyone can confirm the alert actually went out.

Every run is recorded

Each rule keeps its own execution history, which is where you look when an alert failed to arrive.

The record that triggered the run
When it started and when it finished
A status of pending, success, partial failure, or failed
Per-action outcome, with the error text when one fails

A webhook answering outside the 2xx range is recorded as a failure carrying the status code it returned. The request body sent and the response body received are held only for the duration of the call, so the log tells you that a dispatch failed and what the far end said about it.