Alert notifications
Email, Slack, Teams, webhooks, services and topics - and what to configure before anything arrives.
A rule that trips has to reach someone. Zato delivers alerts in seven ways, and until you configure at least one of them, alerts are raised and recorded but nothing is sent anywhere.
The seven delivery actions
| Action | What it does | What it needs |
|---|---|---|
email | Sends the alert as an email | The default.alerts.notifications SMTP connection and a recipient address |
slack | Posts the alert to a Slack channel | The default.alerts.notifications Slack connection and a channel |
teams | Posts the alert to a Microsoft Teams channel | The default.alerts.notifications Teams connection and a channel |
webhook | POSTs the alert as JSON | The URL to POST to |
invoke-service | Invokes one of your own services with the alert | The service name |
publish-to-topic | Publishes the alert to a pub/sub topic | The topic name |
diagnose | Asks a language model what went wrong, then delivers the diagnosis | An active LLM connection |
The first four are where alerts go for people to read. invoke-service and publish-to-topic are where they go for something else to act on - opening a ticket, failing over, throttling a caller, whatever your own code decides.
diagnose reads the failing events behind the alert and produces a written explanation of what appears to be wrong, delivered like any other alert. It is the action attached to the error-rate-with-diagnosis rules on the rules page, turned on and off by the LLM switch on each card.
What to fill in first
Every environment is created with four placeholder connections, all inactive and all with blank details:
| Connection | Type | Name |
|---|---|---|
| Slack | Chat | default.alerts.notifications |
| Microsoft Teams | Chat | default.alerts.notifications |
| SMTP | default.alerts.notifications | |
| LLM | Outgoing | default.alerts.llm |
These names are what the alerting engine delivers through. If a deployment needs different names, set the Zato_Alerts_Connection and Zato_Alerts_LLM_Connection environment variables and the connections are created and used under those names instead.
To make email work:
- In Dashboard, go to
Connections->Email->SMTPand editdefault.alerts.notifications. Fill in your mail server's host, port, username and password, tickActiveand save. - Set the recipient and sender addresses -
email_toandemail_fromunder thealert_notificationskey in enmasse, oraddressesin a rule's own action configuration.
Slack and Teams work the same way: fill in and activate the chat connection named default.alerts.notifications and the alerts are posted to the channel a rule names in its action configuration - slack_channel for Slack, teams_to for Teams.
The plain webhook needs no connection, only its URL - webhook_url in enmasse or in a rule's own action configuration.
The Dashboard URL
The dashboard_url value, set through enmasse, is worth filling in even though nothing fails without it.
Every alert includes a link back into the audit log, filtered to the object the alert is about. When the event that failed is one that can be resubmitted, the link also arms the resubmit action, so following it from an email takes you to the failed message with the retry ready. Without dashboard_url the link is relative and only works if you are already in Dashboard.
Set it to the address your team reaches Dashboard at, for instance https://zato.example.com.
Sending an alert somewhere else
The webhook action posts JSON, so anything that accepts an HTTP POST is a valid destination - PagerDuty, Opsgenie, Jira automation, an internal chat bridge or your own endpoint. Put its URL in webhook_url and the alerts arrive there.
If the receiving system needs a shape Zato does not produce, use invoke-service instead and write the request yourself in a service. That also covers anything needing authentication beyond a URL.