Deployment notifications
Send release results to chosen destinations and inspect delivery separately.
Self-hosted alpha.19 adds application-scoped email, Slack, Discord and signed webhook notifications. Open Deployments → Notification settings. Each application can configure up to five destinations for success, failure and cancellation. Nothing is enabled by default.
Set up a destination#
Give the destination a name, choose its channel and enter the recipient or incoming webhook URL. For generic webhooks, configure a random signing secret in Hakopod and your receiver. Choose events, review the settings, save and send a test.
Email requires operator-configured SMTP. A destination can be saved paused while SMTP is unavailable. Webhooks require a public HTTPS endpoint on port 443; private addresses and redirects are rejected. Destination credentials are encrypted and write-only.
Separate release results from delivery#
A durable PostgreSQL outbox records notification work when a deployment reaches a terminal result. Sending failures do not change the deployment result. Recent delivery history shows attempts and sanitized failure details.
Delivery is at least once with bounded retries. A receiver can accept a message even if the response is lost. Deduplicate generic webhook events using their stable event ID. Five attempts and a 24-hour deadline bound retry work. Editing a destination skips pending jobs for the older revision; an already in-flight send may finish.
Test the real path#
A queued test is not proof that the destination received it. Check delivery history and your receiving channel. A deployment success notification describes the release result at that time; use observability for continuing service health.
Read the versioned notification reference for signatures, permissions, limits and provider setup.