Set up alerts

Who this is for: admins who want to hear about problems before their users do.

Before you start: nothing, for the default email alerts. To add channels you need the Manage connections permission (manage_connections) and must be signed in as a person.

Liitora watches your workflows for you. When something goes wrong it opens an incident and tells the right people. This page explains what happens by default and how to send alerts somewhere else.

In Monitor, select Alerts to see incidents and to set up channels, rules and notification settings. See the Alerts page. Everything also works through the REST API, as shown on this page.

What you get by default

Without any setup:

• Admins get an email when something goes wrong: a workflow fails, misses its deadline, a schedule misfires, the run limit is close or reached, or a secret is about to expire. Admins who turned off alert emails do not get them.
• One email per problem, not per run. Repeats of the same problem are counted on the same incident. You get another email only after the cooldown (60 minutes by default).
• A “works again” email when a later run of the workflow succeeds.
• A weekly health digest every Monday from 08:00 (time zone Europe/Helsinki by default) to every admin: runs, success rate, failures per workflow, open incidents, runs with warnings, compute used against your plan and credentials that expire within 30 days.

What starts an alert

Event	When
run_failed	A production run failed.
run_recovered	A run succeeded after an incident was notified.
repeated_failure	A workflow failed a number of times in a row (you set the number).
freshness_violation	A workflow did not succeed by its deadline. See Set freshness expectations.
quota_warning	Runs this month passed 80% or 100% of your plan’s soft limit.
quota_exceeded	Runs this month reached your plan’s hard limit, or runs were refused for another reason (for example an unpaid account). New production runs are not started.
trigger_misfire	Scheduled runs were missed, for example during an outage, or a schedule runs more often than your plan allows.
credential_expiry	A secret expires in 30, 7 or 1 day(s), has expired, or an OAuth connection needs to be reconnected.
anomaly	A run succeeded, but a number it reported was outside the bounds you set. See Anomaly thresholds.
connection_degraded	A connection kept failing, so runs that use it now wait instead of calling it. One alert per outage. See A connection keeps failing.
library_item_flagged	Liitora flagged a version of a library workflow your company copied. One alert per flagged version, and your admins are always emailed, even when rules exist. See If Liitora flags a version you use.
runner_unavailable	Runs of one of your runner groups waited more than 10 minutes, and no runner of the group contacted Liitora in that time. One alert per outage. See Run automations in your own environment.

Test runs and dry runs never start alerts.

Incidents

An incident groups repeats of one problem: one open incident per workflow and cause. The cause is the failing step, or the error code. Each incident counts how often it happened and how many failures came in a row, and it has a plain summary of the likely cause and what to do.

An incident closes by itself when a later run succeeds. You can also close it by hand: select Mark as resolved on the Incidents page, or use POST /api/v1/incidents/{id}/resolve (needs Edit workflows). Your AI assistant can explain a failure with the get_incident tool.

To list incidents, use GET /api/v1/incidents (needs View runs; open=true for open ones only).

Send alerts to other places

A channel is a place alerts go. A rule sends one kind of event to one channel.

In the app: on Alerts, open Channels and select Add a channel, then open Rules and select Add a rule. Use Send a test to check a channel.

Channels

Kind	Where it posts	What you need
email	One email per person. Set roles (default tenant_admin) and extra addresses in the channel’s config.	Nothing else
teams	A Microsoft Teams card, to an incoming webhook or workflow address on *.webhook.office.com, *.logic.azure.com or *.powerplatform.com	A Text secret with the webhook address
slack	A Slack message, to an incoming webhook on hooks.slack.com	A Text secret with the webhook address
webhook	JSON to your own HTTPS address (config.url), signed	An API key secret with the signing key

The Teams and Slack webhook addresses work like passwords, so they are stored as secrets, not in the channel. If the secret does not exist yet, Liitora creates a request for it with a fill link. Posts only go to public HTTPS addresses, and redirects are not followed.

A webhook channel signs every post the same way Liitora signs outgoing webhooks: an X-Liitora-Timestamp header and X-Liitora-Signature: sha256=<hex>, the HMAC-SHA256 of <timestamp>.<body> with the signing key. See Webhook signing.

To add a Slack channel:

1. Create an incoming webhook in Slack and copy its address.
2. Create the channel with POST /api/v1/notification-channels:

{ "name": "ops-slack", "kind": "slack", "config": {}, "secret_ref": "slack_ops_webhook" }

3. Open the secret_fill_url in the answer and paste the Slack address.
4. Send a test post with POST /api/v1/notification-channels/{id}/test.

Creating, changing, testing and deleting channels needs a signed-in person with Manage connections.

Rules

A rule says: send this event, for this workflow (or all workflows), to this channel.

{ "event": "run_failed", "channel_id": "<channel id>", "delivery": "instant" }

• Leave out workflow_id for all workflows.
• delivery is instant (default) or daily_digest: entries are collected and sent as one message per channel at the hour set in daily_digest_hour.
• For repeated_failure, set threshold: the rule notifies once when a workflow fails exactly that many times in a row.

Create rules with POST /api/v1/alert-rules. Rules need Manage connections. Your AI assistant can manage rules too, if its access includes that permission.

When there are no matching rules, every event except anomaly and repeated_failure goes to your admins by email, as described above. Once a rule matches an event, it goes where the rule says.

Delivery and retries

Every notification is recorded, and you can see them with GET /api/v1/notification-deliveries. A failed post is tried up to 5 times: after 1 minute, 5 minutes, 30 minutes and 2 hours. Answers such as 408, 429 and 5xx are retried. Other errors stop at once.

Anomaly thresholds

A workflow can report numbers with ctx.metric("invoices", 42) in a script. You can set bounds for each number with PUT /api/v1/workflows/{id}/metric-rules (needs Edit workflows):

{ "items": [ { "metric": "invoices", "min": 1, "max": 5000 } ] }

When a run succeeds but a number is below min or above max, the run shows as succeeded with warnings, and an anomaly incident opens. The next run with the number inside the bounds closes it. A missing number is not an anomaly.

Notification settings

Company-wide settings are on the Notifications page, and with GET and PUT /api/v1/notification-settings (changing them needs a signed-in person with Manage connections):

Setting	Default	Meaning
timezone	Europe/Helsinki	Time zone for the digests
cooldown_minutes	60	How long to wait before notifying about the same incident again
daily_digest_hour	8	Local hour (0 to 23) when daily digests are sent
weekly_digest	on	Whether the weekly health digest is sent

Each person can turn off their own alert emails and weekly digest under Your emails on the same page, or with PUT /api/v1/me/notification-preferences:

{ "alert_emails": false, "weekly_digest": true }

Alert and digest emails come from Liitora’s own address, not from your company’s sender.

Next steps

• Set freshness expectations
• Read run logs
• Understand usage and limits