A deployment should not require keeping a browser tab open just to learn how it ended. It should also not fill every channel with messages no one reads.
Application notifications in Hakopod alpha.19 give each application its own destinations and event choices. Send success, failure or cancellation to email, Slack, Discord or a signed webhook. Start with the events someone will actually act on.
Give the message an owner
An application can have up to five destinations. That is room for different responsibilities: perhaps failures go to the people operating the service while a release feed records successful changes.
Nothing is enabled by default. Review the recipient or webhook, select the events and send a test. Email depends on the installation’s SMTP configuration. Webhooks need a public HTTPS endpoint on port 443; an internal-only receiver will not work.
A saved configuration and a queued test are steps along the way. Check that the message arrived in the real destination. A successful local receiver test does not prove that your Slack channel, mail provider or webhook endpoint is configured correctly.
The rollout and the message are separate work
When a deployment reaches a final result, Hakopod records notification work in a PostgreSQL outbox. Delivery happens afterward. If a provider is unavailable, that does not turn a successful deployment into a failed one.
This separation also explains why delivery history exists. A missing message can mean a rejected destination, a timeout or exhausted retries. Look at the delivery result before rerunning the deployment to get another notification.
Retries are bounded, and delivery is at least once. A receiver might accept the event just before the connection fails. A generic webhook consumer should use the stable event ID to recognize a duplicate rather than treating every HTTP call as a new release.
Success has a timestamp
A success message says that the deployment reached its successful result. It does not say that the application will remain healthy tomorrow, or that an application-level bug has been fixed.
Use health observations and alarms for continuing problems. Use a replay or a targeted application check to verify the behavior that motivated the release. These signals can point to the same application while answering different questions.
That distinction keeps a notification useful. You can read it as a specific result instead of an overbroad promise, and the people receiving it know what to do next.
Follow the notification guide to configure a destination, test delivery and inspect failures without losing the release context.