Skip to main content
Slipway has two notification surfaces: channels that POST deployment events out to Slack / Discord / your own tooling, and the in-app inbox that tells you about things inside the console.

Channels

Set up channels once under Settings → Notifications (admins only), then subscribe repos to them. For a generic webhook you can set an HMAC signing secret; slipway then signs each POST with X-Slipway-Signature: sha256=<digest> over the raw body, so your receiver can verify it. URLs and secrets are encrypted at rest and shown masked in the UI. Each channel row has a Send test button — confirm the endpoint is reachable before subscribing a repo. Delivery is fire-and-forget: a failed POST records a notification_failed event on the deployment and never blocks the deploy.

Subscribing a repo

On a repo’s Notifications page, every org channel appears as a row. Tick which events should fire on each: Nothing fires until you tick at least one event — there’s no implicit “everything”. Changes save as you toggle, and the Enabled switch lets you mute a channel without losing its event filter.

In-app inbox

The inbox is the bell in the top bar — per-user, live, and where slipway surfaces things you’d otherwise miss: A new notification slides in as a toast and bumps the bell’s unread badge; the Notifications page (from the bell’s “See all”) lists everything with an All / Unread filter. Org-level alerts like limit reached also fan out to your channels if any are set up — no extra config.

Emails

Slipway also emails you about things worth knowing when the console isn’t open: a deploy that failed, a teammate who joined or whose access changed, a custom domain that went live, and billing events like a trial ending or a payment that didn’t go through. Your first sign-in gets a short personal welcome. Account-critical mail (billing and access changes) always sends; activity mail can be switched off from the Manage email preferences link in any email footer. Who hears about each depends on the event: deploy failures go to whoever triggered the deploy, while org-level events go to owners and admins.