> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Notifications

> Send deployment events to Slack, Discord, or your own webhook — and the in-app inbox.

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.

| Type                | What you provide                                                                                                     |
| ------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Discord**         | A channel webhook URL. Slipway posts a colour-coded embed (green healthy, blue updated, red failed, grey torn down). |
| **Slack**           | An incoming-webhook URL, same colour coding.                                                                         |
| **Generic webhook** | Any HTTPS endpoint that accepts a JSON POST. See the [payload reference](/reference/notification-payload).           |

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:

| Event       | Fires when                                                         |
| ----------- | ------------------------------------------------------------------ |
| `healthy`   | A new preview reached healthy with live URLs.                      |
| `updated`   | A new commit produced a fresh preview that superseded a prior one. |
| `failed`    | A build or deploy failed.                                          |
| `torn_down` | An ephemeral preview expired and was cleaned up.                   |

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:

| Notification                 | Who gets it                                                                                                     |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------- |
| **Deployment limit reached** | Owners + admins — e.g. a PR preview that couldn't start because you're at your [plan cap](/organization/plans). |
| **Deployment failed**        | Whoever triggered the deploy.                                                                                   |
| **Support reply**            | The user whose ticket it is.                                                                                    |

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.