Fan-out

import { Aside } from ‘@astrojs/starlight/components’

Fan-out lets a deployment receive a copy of every webhook alongside whichever deployment the request actually routed to — useful for a staging environment that should see production traffic, an analytics sink, or a second team that needs the same events without owning the routing rules.

How it works

Flag a deployment as a fanout target and it starts receiving a copy of every webhook delivered to the project:

On the default path (no rule matched, or none configured), fanout targets always get a copy.
On a rule match, fanout targets get a copy only if that rule also has fanout enabled.

Each fanout delivery is logged separately and counts toward your monthly quota, the same as the primary delivery.

Fanout deliveries are fire-and-forget — they run in the background after the response to the original webhook has already been sent. A slow or failing fanout target never delays or affects the response your provider sees.

Enabling fanout

Dashboard: Project → Routing → pick a deployment → Set fanout

A deployment can’t be both active (the default target) and a fanout target — activating a deployment automatically clears its fanout flag, since the active deployment already receives every webhook.

Per-rule fanout

Fanout is off by default on a rule match. To also mirror traffic to your fanout deployments when a specific rule matches, enable the Fanout checkbox when creating or editing that rule (Project → Routing → rule editor).

Fanout and local tunnel mode

A fanout target that also has local tunnel mode on (hookman listen) is relayed over the tunnel to your machine, the same as the primary route would be — it does not fetch the deployment’s stored target URL. Fanout and local tunnel mode work together.

Plan availability

Fan-out is available on every plan — it’s a per-deployment flag, not gated by plan tier.