More signal than a basic webhook. Less noise than a firehose.
A forge webhook can post an event into a channel. That is genuinely useful, and for a single repository it may be all you need. This page compares that approach with a routing layer. Named comparisons with GitHub Slack, GitLab Slack, Axolo, and PRFlow sit on their own pages.
Named comparisons
When the alternative is a specific product.
Each page uses shipped ForgeRelay behaviour and publicly documented competitor behaviour. No invented pricing.
ForgeRelay vs GitHub Slack app
GitHub’s official Slack app is free, official, and good at slash commands and Copilot in Slack. ForgeRelay is for teams that want one conversation per pull request — and GitLab or Discord in the same product.
Read comparisonForgeRelay vs GitLab Slack app
GitLab’s official Slack app covers a wide event catalogue, slash commands, and GitLab Duo in Slack. ForgeRelay is for teams that want one conversation per merge request — including pipeline recovery — and GitHub or Discord in the same product.
Read comparisonForgeRelay vs Axolo
Axolo creates an ephemeral Slack channel for each pull request and lets the team review bi-directionally from Slack, including /lgtm. ForgeRelay leaves approvals in GitHub or GitLab and posts a quiet living thread instead.
Read comparisonForgeRelay vs PRFlow
PRFlow keeps a live Slack card that shows what is left to merge, and it publicly markets GitHub plus GitLab including self-hosted GitLab. ForgeRelay is the closer fit when Discord, commit digests, delivery replay, or per-route overrides matter.
Read comparisonSide by side
Where a routing layer changes the outcome.
Every row below describes ForgeRelay as designed today against a basic forge-to-chat webhook.
| Capability | Basic forge-to-chat notifications | ForgeRelay |
|---|---|---|
| Per-repository routing | One webhook per repository and channel | Routes built from searchable repositories and channels |
| Multiple event types per rule | No | Review, merge and pipeline events share one route |
| One living thread per request | A separate channel message per event | First event posts, later events update the thread |
| Mapped reviewer mentions | Prints the forge handle | Mentions the mapped Slack or Discord user |
| Stale review reminders | No | One quiet nudge per threshold |
| Pipeline failure and recovery | Failure only, detached from the request | Failure and recovery inside the request thread |
| Per-route behaviour | No | Default / On / Off overrides over workspace defaults |
| Custom PR/MR status colours | No | One organisation palette across Slack and Discord |
| Delivery logs and replay | Provider-side delivery attempts only | Recorded payloads with replay when a destination fails |
| Commit digests | Posts every push as a separate message | One filtered digest per push — branch, author, type |
-
Per-repository routing
- Basic forge-to-chat notifications
- One webhook per repository and channel
- ForgeRelay
- Routes built from searchable repositories and channels
-
Multiple event types per rule
- Basic forge-to-chat notifications
- No
- ForgeRelay
- Review, merge and pipeline events share one route
-
One living thread per request
- Basic forge-to-chat notifications
- A separate channel message per event
- ForgeRelay
- First event posts, later events update the thread
-
Mapped reviewer mentions
- Basic forge-to-chat notifications
- Prints the forge handle
- ForgeRelay
- Mentions the mapped Slack or Discord user
-
Stale review reminders
- Basic forge-to-chat notifications
- No
- ForgeRelay
- One quiet nudge per threshold
-
Pipeline failure and recovery
- Basic forge-to-chat notifications
- Failure only, detached from the request
- ForgeRelay
- Failure and recovery inside the request thread
-
Per-route behaviour
- Basic forge-to-chat notifications
- No
- ForgeRelay
- Default / On / Off overrides over workspace defaults
-
Custom PR/MR status colours
- Basic forge-to-chat notifications
- No
- ForgeRelay
- One organisation palette across Slack and Discord
-
Delivery logs and replay
- Basic forge-to-chat notifications
- Provider-side delivery attempts only
- ForgeRelay
- Recorded payloads with replay when a destination fails
-
Commit digests
- Basic forge-to-chat notifications
- Posts every push as a separate message
- ForgeRelay
- One filtered digest per push — branch, author, type
Stay with webhooks
A webhook is fine when…
- One repository posts into one channel
- Everyone reviewing already watches that channel closely
- You only care that something happened, not who should act
- Pipeline results are read in the forge, not in chat
Add a relay
A relay earns its place when…
- Several repositories need different destinations
- Review requests should reach a named person
- PR and MR states should match the team’s visual language
- The channel is getting six messages per request
- Pipeline failures need the recovery attached to them
- A missed delivery has to be explainable and replayable
Keep pull requests moving.
Free for up to 3 mapped people. Unlimited repos and notifications. No credit card.