> ## 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 platform events to Slack, Discord or your own endpoint, with per-channel event selection and automatic retries.

There are two notification surfaces: **channels**, which deliver events out to Slack,
Discord or your own tooling, and the **in-app inbox**, which surfaces things inside the
console.

## Channels

Set channels up under **Settings → Notifications** (requires admin). Each channel is a
destination plus its own selection of [event types](/reference/webhook-events): pick any
combination from deploys, services, previews, projects, and organization events, and change
the selection anytime.

| Type | What you provide |
| - | - |
| Discord | A channel webhook URL. slipway posts a colour-coded embed: green for success, red for failures, amber for warnings, grey for teardowns. |
| Slack | An incoming-webhook URL, with the same colour coding. |
| Generic webhook | Any HTTPS endpoint that accepts a JSON POST. See the [webhooks reference](/observability/webhooks) for the schema, signatures, and delivery guarantees. |

For a generic webhook you can set an HMAC signing secret; slipway then signs every delivery
so your receiver can verify authenticity and reject replays. URLs and secrets are encrypted
at rest and shown masked.

Each channel has a **Send test** button that pushes a synthetic event through the real
delivery pipeline (headers, signatures and all) so you can validate your receiver before
any real event fires.

## Delivery, retries, and auto-disable

Delivery is durable. A failed attempt (non-2xx, timeout, or connection error) retries up
to 8 times with exponential backoff over roughly 33 hours. If every attempt fails, the
channel is **disabled automatically**: your org's admins get an inbox notice, the remaining
channels get a message, and the channel's page shows why. Fix the endpoint, then hit
**Re-enable** to resume.

Every channel page has a **Deliveries** tab listing recent deliveries with status, attempt
count, and last HTTP code. Click a row for the full payload and last error, and use
**Redeliver** to send any event again. History is kept for 30 days.

## Scoping a channel to projects

By default a channel receives its selected events from **every project** in the
organization. To narrow it, open a project's **Settings → Notifications** and toggle the
channel on for that project: as soon as a channel is toggled on anywhere, it only fires for
the projects it's toggled on for. Organization events (members, billing, domains) ignore
scoping.

## The in-app inbox

The inbox is the bell in the top bar: per-user, live, and where slipway surfaces things you
would otherwise miss.

| Notification | Who gets it |
| - | - |
| Deployment limit reached | Owners and admins, when a deploy could not start because of a plan cap |
| Deployment failed | Whoever triggered the deploy |
| Support reply | The user whose ticket it is |
| Balance running low, or out of credit | Owners and admins |
| A service grew on its own | Owners and admins, when [automatic compute](/services/automatic-compute) raised an allocation |
| A service is running hot | Owners and admins, when a [usage alert](/observability/usage-alerts) fires. This one also goes to your channels. |
| A service is at its ceiling | Owners and admins, when it cannot grow further and is still running hot. This one also goes to your channels. |
| A service looks oversized | Owners and admins, with what a smaller allocation would save. Advice only. |
| A notification channel was disabled | Owners and admins, after a channel exhausted its delivery retries |

A new notification arrives as a toast and bumps the bell's unread badge. The
**Notifications** page lists everything with All, Unread and Read filters; selecting one
opens its full story, and notifications with a fix — a usage alert, say — offer it right
there.

Organization-level alerts such as a limit being reached also fan out to your channels when
any are set up, with no extra configuration.

## Emails

slipway emails about things worth knowing when the console is not open: a deploy that
failed, a teammate who joined or whose access changed, a custom domain that went live, and
billing events such as a payment that did not go through.

Account-critical mail, meaning 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, and organization-level events go to owners and admins.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.