Slack Integration

Rack Gateway can forward audit log events to Slack. Notifications are routed by action patterns that match the audit log action field.

Features

OAuth-based connection to a Slack workspace
Every message names the gateway that sent it, so several gateways can share one Slack app
Channel routing using glob patterns
Test notifications per channel
Dedicated deploy approval alert channel (optional)

Setup

1. Create a Slack App

Go to https://api.slack.com/apps
Click Create New App → From an app manifest
Select your workspace
Paste this manifest (update redirect_urls)

{
  "display_information": {
    "name": "Rack Gateway",
    "description": "Audit notifications",
    "background_color": "#2c2d30"
  },
  "features": {
    "bot_user": {
      "display_name": "Rack Gateway",
      "always_online": true
    }
  },
  "oauth_config": {
    "redirect_urls": [
      "https://your-gateway-domain.com/api/v1/integrations/slack/oauth/callback"
    ],
    "scopes": {
      "bot": ["channels:read", "chat:write"]
    }
  },
  "settings": {
    "org_deploy_enabled": false,
    "socket_mode_enabled": false,
    "is_hosted": false,
    "token_rotation_enabled": false
  }
}

2. Configure Environment Variables

SLACK_CLIENT_ID="your-client-id"
SLACK_CLIENT_SECRET="your-client-secret"

The bot token Slack returns is stored encrypted with COLUMN_ENCRYPTION_KEY (see Column Encryption). If that key changes, notifications stop and are reported in the logs until you reconnect Slack.

3. Connect via Web UI

Log in as an admin
Navigate to Integrations
Click Connect to Slack
Authorize the app in Slack
Invite the bot to each channel it should post in (/invite @Rack Gateway). With the chat:write scope a bot can only post in channels it belongs to, and the channel picker lists public channels only
Configure channel routing

Connecting, changing channels or alerts, sending a test and disconnecting are admin actions that need a recent MFA verification (the step-up window). Disconnect removes the integration and its stored bot token.

Channel Configuration

Each channel has:

A selected Slack channel
A list of action patterns (glob syntax)

Add Channel adds another channel config. Each change is saved straight away. If someone else changed the configuration since your page loaded, the save is refused with “The channel configuration changed since it was loaded. Showing the latest; make your change again.” and the page reloads the current configuration, so one admin never overwrites another’s change.

Default Channels

The gateway creates two default channel configs:

#security

login.complete
login.*_failed
mfa_method.*
mfa.verify_failed (a failed MFA verification, in the web UI or for a CLI login)
user.update_roles
api_token.*
env.*_protected
audit_log.verification_* (the hourly audit verification failing, and passing again after failing; a passing run posts nothing)

#infrastructure

deploy_approval_request.*
release.promote

Action Pattern Examples

Pattern	Matches
`login.*_failed`	`login.oauth_failed`, `login.user_not_authorized`
`mfa_method.*`	MFA enrollment events
`api_token.*`	API token create/update/delete
`env.*_protected`	Protected env var changes and removals (`env.set_protected`, `env.unset_protected`), including refused `--allow-protected` attempts while the step-up window is open
`deploy_approval_request.*`	Request create/approve/reject
`release.promote`	Release promotions
`user.*`	User create/update/delete/lock/unlock

Testing

Each channel card includes a Test button that sends a test message, naming the gateway, to the selected Slack channel. If it fails with not_in_channel, invite the bot to that channel.

Patterns use Go’s filepath.Match syntax: * matches any run of characters, ? one character, and [...] a character class. A pattern must match the whole action, so login matches nothing; use login.*.

Deploy Approval Alerts

The Slack integration also supports a dedicated Deploy Approval Alerts channel:

Enable the alert toggle
Choose a single Slack channel
When a deploy approval request is created, the gateway posts an alert with the request’s details and a link to approve it in the web UI, regardless of action patterns

Approving and rejecting happen in the web UI or CLI; Slack only notifies. Route deploy_approval_request.* to a channel to hear about approvals and rejections too.

Message Formatting

One gateway runs per rack, and several gateways can post to the same Slack workspace through one Slack app, so every message names the gateway that sent it. The first line is Rack Gateway (<RACK_DISPLAY_NAME>), linked to the gateway, and the notification text starts with Rack Gateway (<RACK_DISPLAY_NAME>): . Set RACK_DISPLAY_NAME on each gateway (for example Staging or US); it defaults to RACK_ALIAS, then RACK. Emails from the gateway use the same name.

Audit event messages then include:

Action name
User or API token
Status
Timestamp
Context fields (when available)
The audit entry’s details. For env var changes, values are [REDACTED] unless the app lists the key in audit_visible_env_vars; rack parameter changes name the parameters only. See Secret Redaction.

Example action:

Rack Gateway (Staging)
🚀 deploy_approval_request.approved
User: admin@example.com
Status: success

Deploy approval alerts start with the same line, and their View Approval Request link opens the request on that gateway.

Values that come from CI or from users (branch, message, names, resources, audit details) are escaped, so they show as written and can’t mention anyone or add links. The pull request and CI build links appear only for https:// URLs, and the CI build link names its host. Long messages and audit details are shortened to fit in a Slack message.

Audit Logs - Action names and filters
Deploy Approvals - Approval workflow