Skip to main content

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.

Each repo can subscribe to one or more org-level notification channels and choose which deployment events should fire on each.

​
Where to find it

/{slug}/repos/{id}/notifications — the Notifications row under the repo’s Settings tab. Developers and admins can edit; viewers can read.

​
Per-channel event filter

Every channel defined at the org level appears as one row. For each:
  • Events — tick the events you want delivered on this channel:
    EventWhen
    healthyA new preview reached healthy and public_urls is populated.
    updatedA new push to the same PR (or branch) produced a fresh preview that superseded a prior one.
    failedThe build / release / deploy step errored out.
    torn_downAn ephemeral preview’s TTL expired and the namespace was garbage-collected.
  • Enabled — soft-off without losing the event filter. Useful while debugging a flaky receiver.
Changes save as you toggle — no separate “Save” button.

​
How healthy vs updated is decided

When a deployment flips to healthy, slipway checks for any prior superseded or cancelled deployment of the same PR (or, for non-PR deploys, the same branch). If one exists, the event is sent as updated. Otherwise it’s healthy. Subscriptions can listen to either independently — most teams want both ticked.

​
When nothing happens

  • No channels at the org level — set one up under Settings → Notifications first. The repo page will show an empty state with a CTA.
  • No event ticked — every event must be ticked explicitly. There’s no implicit “fire on everything”.
  • Channel disabled — flip the Enabled switch back on.
  • Receiver rejected the POST — slipway records a notification_failed deployment event with the channel id and HTTP status. Check the deployment timeline on the deployment detail page.

​
Cleanup

Deleting a channel at the org level removes every subscription pointing at it; there is no separate cleanup step on the repo side. Removing a repo subscription leaves the channel intact for other repos.