Destinations

Destinations are where Watchtower sends events after they've been received and verified. Each destination is a URL in your own infrastructure. When an event arrives at a source, it's delivered to every active destination attached to that source.

Adding a destination

1. Go to Destinations in your workspace.
2. Click Add destination.
3. Enter the URL your application exposes for webhook delivery.
4. Select which source (or sources) this destination should receive events from.
5. Save.

Events start flowing immediately. Each new event arriving at the linked source is queued for delivery to this destination.

Fan-out to multiple destinations

You can attach multiple destinations to a single source. Each event is delivered to all active destinations independently. A failure on one destination doesn't affect delivery to the others, and each destination has its own retry queue.

Common uses for fan-out:

• Production and staging in parallel: one destination at your production endpoint, one at staging. Both receive every event.
• Multiple services: a single Stripe source delivering to a billing service, a notification service, and an analytics service.
• Logging and processing: forward to an internal endpoint and also to a logging pipeline.

Local development

To receive webhooks locally, expose your dev server using a tunnelling tool like ngrok or Cloudflare Tunnel. Add the public tunnel URL as a destination.

Events forwarded to your local machine appear alongside any other destinations. You can also replay past events from the dashboard without triggering a new event from your provider.

Pausing a destination

Disabling a destination pauses delivery to that endpoint without removing it. Events continue arriving at the source and queuing for other active destinations. The paused destination misses those events. They won't be retroactively delivered when you re-enable it.

Use this when taking a destination endpoint down for maintenance. If you need a guarantee that no events are missed, replay the relevant events from the dashboard after bringing the endpoint back up.

Timeouts

Delivery attempts time out after 10 seconds. If your endpoint doesn't respond within that window, the attempt is marked as failed and retried. To avoid timeouts, return a 200 immediately and process the payload asynchronously in a background job.

Destination URL requirements

• Must be a publicly accessible HTTPS URL (or plain HTTP for local dev tunnels)
• Must return a 2xx status code for delivery to be considered successful
• Any non-2xx response or timeout triggers a retry