Notifications
Admins set notifications in Administration > Settings. Every channel has a test button.
What is sent
| Kind | Examples | Slack / Teams | Email (default) | PagerDuty (default) |
|---|---|---|---|---|
| Failure | A runbook or workflow failed, a schedule could not start | yes | yes | yes |
| Action needed | A run waits for approval, the audit-log alarm needs a second person | yes | yes | no |
| Information | Drift detected, a workflow succeeded, new machines joined | yes | no | no |
Slack or Microsoft Teams
Paste an incoming-webhook address under Notifications and choose Save. Every notification is posted.
Under Email, fill in:
- SMTP server, Port and Security: STARTTLS (usually port 587), TLS (usually port 465), or none for a relay inside your network.
- From: the sender address.
- User name and Password, if the server needs them. The password is stored sealed with the server's key and never shown again. Changing the SMTP server discards it, so a saved password is never sent to a new server.
- Send to: one or more addresses.
- Which kinds to email: failures, approvals waiting, everything else.
PagerDuty
Create an Events API v2 integration on the PagerDuty service that should be paged, and paste its integration key under PagerDuty. Failures open an incident. The key is stored sealed and never shown again; tick Remove and save to delete it.
A runbook's own recipients
When an admin creates a runbook, Email when it finishes takes one or more addresses. Those addresses get an email every time the runbook finishes, success or failure, in addition to the addresses in Settings. Email must be set up in Settings first.
Delivery
Gardience checks every address like other addresses an admin configures (never loopback or cloud metadata addresses) and connects only to the address it checked. A failed delivery shows in Settings and in the console's problem banner; it never stops the run that was reporting.