Hakopod can send a message when a deployment succeeds, fails or is cancelled, so you can leave the dashboard and still receive the result.
Application notifications, added in alpha.19, support email, Slack, Discord and signed webhooks. Each application has its own destinations and event choices. Start with the events someone will 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.
A successful deployment still needs a behavior check
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.
Follow the notification guide to configure a destination, test delivery and inspect failures without losing the release context.