Pipeline Wednesday: Stripe to Slack, but with the rules every team learns the hard way

Every startup wires Stripe to Slack in week one. Most rewire it in month six because the noise drowns the signal. Here is the version of the pipeline that survives both.

The starter version most teams ship

Stripe webhook -> a single endpoint -> post the JSON to a Slack channel. It works for two weeks. By month two, the channel is unreadable.

The version that survives

Three filters and one router. The filters cut the noise down to the events that matter. The router sends the event to the right Slack channel for the right team.

Filter 1: Event type allowlist

You probably do not need every event Stripe sends. Pick the 8-10 that map to a human action: charge.succeeded, charge.refunded, customer.subscription.created, customer.subscription.deleted, and a few more. Drop the rest.

Filter 2: Amount threshold

For charge.succeeded below a small threshold, log silently. Above it, post. Saves the channel from the dollar-amount drip.

Filter 3: Dedup window

Stripe sometimes retries. Add a 60-second dedup keyed on event.id and you eliminate 90% of duplicate noise.

Router: Channel selection

Subscriptions to the growth channel. Refunds to the support channel. Failed charges to the engineering channel. Each team sees what they actually own.

The escalation rule

If three failed charges happen within five minutes - or any single charge above a critical threshold - escalate to PagerDuty, not just Slack. Most outages have a Stripe-side fingerprint before they have a customer-side complaint.

The code

The full pipeline is 80-120 lines depending on how strict you make the dedup. Whether you build it on a queue, on Cloudflare Workers, or in Temporal does not matter much - the rules above are 90% of the value.

Next week

Pipeline Wednesday #2 - Klaviyo to Postgres, the version that handles the multi-tenant case.