Deployment notifications
Send release results to chosen destinations and inspect delivery separately.
Self-hosted alpha.19 adds application-scoped email, legacy Slack webhooks, 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.
Legacy direct Slack webhooks, including a generic webhook that points to a Slack-hosted URL, require Hakopod Pro on a self-hosted installation. On Hakopod Cloud, direct application-level Slack webhooks are unavailable. When the integration is released, use Settings → Integrations → Slack so the workspace owner can connect the central Hakopod Cloud Slack app and choose its events. Until then, Slack notifications remain unavailable. A saved legacy Slack destination can still be paused, deleted or changed to email, Discord or a non-Slack webhook; it cannot be enabled, tested or delivered directly in Cloud.
Check notification delivery#
When a deployment succeeds, fails or is cancelled, Hakopod saves the pending notifications in PostgreSQL. Sending failures do not change the deployment result. Recent delivery history shows attempts and sanitized failure details.
Delivery can produce duplicate messages, and retries have a limit. A receiver can accept a message even if the response is lost. Deduplicate generic webhook events using their stable event ID. Hakopod allows up to five delivery attempts within 24 hours. 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.