Configure
Integrations
Send terminal run notifications to one Slack channel per organization and deliver Entire-native repository events through a credential-scoped relay.
Slack availability
Slack appears in Organization settings only when the production Runnable Slack app and OAuth environment are configured.
Release-aware setup
The distributed Runnable Slack app requests only incoming-webhook. Slack’s authorization screen provides the workspace and channel picker and returns a channel-bound webhook.
Install Slack notifications
Owners and administrators can install, test, update, or disconnect the integration.
- 1
Open Organization settings
Find Slack notifications and select Add to Slack. - 2
Approve the workspace and channel
In Slack, choose the workspace and destination channel, then authorize Runnable. - 3
Select result preferences
Enable any combination of success, failure, and cancellation notifications. - 4
Send a test
Confirm the selected channel can receive a message before relying on it for build operations.
One destination per organization
Notification behavior
Notifications are an at-least-once side effect isolated from the authoritative run conclusion.
| Behavior | Contract |
|---|---|
| When | A terminal run creates one integration/run delivery record. |
| Mapping | success → success preference; failure/timed_out/infrastructure_failure → failure; cancelled/skipped → cancellation. |
| Content | Uses the immutable workflow snapshot captured for the run, not a later definition. |
| Retries | Transient failures retry with persistent exponential backoff for up to 24 hours; bounded Retry-After is honored for HTTP 429. |
| Non-retryable | Invalid, disabled, archived, or missing destinations stop retries and require reinstallation. |
| Delivery guarantee | If Slack accepted a post but Runnable failed before recording sent, an abandoned-delivery retry can produce a duplicate. |
| Build result | Notification failure is recorded separately and never changes the run conclusion. |
Reconnect or disconnect Slack
Use the state shown in Organization settings instead of rotating credentials outside Runnable.
| Action | Effect |
|---|---|
| Change workspace or channel | Starts OAuth again, stores the new encrypted webhook, and keeps preferences. |
| Reconnect required | Shown after an invalid destination or a signed app_uninstalled event; authorize again. |
| Disconnect | Deletes the stored channel credential and delivery history, immediately stopping posts. |
| Uninstall from Slack | A Slack workspace administrator removes the workspace-level app; Runnable disables matching connections after the signed event. |
Disconnecting in Runnable does not uninstall the Slack app at workspace level. Likewise, changing a Slack channel outside OAuth can invalidate the destination and place the integration in Reconnect required.
Operate the Entire event relay
Each Entire-native repository has its own webhook URL and bearer credential. The sender owns cleartext storage; Runnable stores only its hash.
- 1
Persist both values at onboarding
Save the URL and one-time bearer in the relay’s secret manager. - 2
Use unique delivery IDs
Retries reuse the same provider-unique ID so delivery remains idempotent. - 3
Monitor accepted events and runs
A successful relay response confirms acceptance; workflow filters and diagnostics still decide whether a run is created. - 4
Rotate deliberately
Update the sender with the new one-time bearer immediately; the old credential becomes invalid as soon as rotation succeeds.
No overlap window for relay rotation