When the merge gate blocks a PR, ArchRails posts a notification to whichever Slack channel
owns the affected service. Routing is per-team, using your CALM node.owned_by field
(top-level or under metadata) — the same convention as AR-CTRL-OWNER-001.
A wildcard * binding catches services with no team tag. Admin-only.
Loading your account…
Slack integrations are admin-only
You're signed in, but this page requires the admin role on the tenant.
Webhook URLs are credentials — anyone holding one can post to that Slack channel as the
ArchRails bot. To restrict the blast radius, only tenant admins can add, edit, delete, or
test bindings.
Talk to your tenant admin if you need a binding added (or deleted), or email
hello@archrails.io.
Your account isn't provisioned for ArchRails yet
ArchRails is currently invite-only. Email
hello@archrails.io
to request access.
Signed in as
Tenant:
How routing works.
Tag each service in your CALM file with "owned_by": "your-team-name" (top-level
or under metadata). Then bind that team value to a Slack incoming webhook URL
below. When a refusal fires for a service owned by that team, ArchRails posts to that channel
— one message per (PR, team) batch, never per-violation.
Need a webhook URL?
Slack admin → Apps → Custom Integrations → Incoming Webhooks →
add to a channel → copy the URL it gives you.
Always add a default fallback (*).
It catches services with no owned_by tag, including new ones added before they're
properly tagged. Without it, those refusals silently land nowhere.
Add or update a team binding
Re-using a team value replaces the existing binding (no duplicate rows).
Test the webhook before saving with Send test message.
Same string you put in node.owned_by. Use * for the
catch-all fallback channel.
Stored encrypted at rest. Never returned in API responses — only a 12-char fingerprint
so you can spot when it changes.
Cosmetic — Slack derives the real channel from the URL.
Current bindings
⏳
Loading…
The publisher fires only when the merge gate blocks a PR
(display_status=fail). Warnings and clean reviews are not Slack-worthy —
the GitHub PR comment is the authoritative surface. Slack is the broadcast.
Slack being down never delays or fails the PR pipeline.