What Stripe events should a founder monitor?

The Stripe events to monitor as a founder fit in three tiers. Act now covers disputes, failed payments, and failed payouts. Read today covers new subscribers, cancellations, refunds, and large payments. Digest covers every successful charge, which belongs in a daily summary instead of a ping per payment. Stripe has hundreds of webhook events, but about a dozen matter to a founder.

Three tiers of Stripe events to monitor

A common mistake is treating every Stripe event as equally important. A dispute with a response deadline and a $15 fee is not the same as a routine $29 renewal. Before you turn on any alert, ask whether the event needs an interruption or can wait for a scheduled read.

Tier 1 is money leaving your account or a deadline running, and you want to know within the hour. Tier 2 is context you should read the same day, in a channel that finance, support, and founders can all see. Tier 3 confirms things are working and is useful only as a total.

• Tier 1, act now. Disputes, failed payments, failed invoices, and failed payouts. Money or a deadline is at stake.
• Tier 2, read today. New subscribers, cancellations, refunds, large payments, and plan changes.
• Tier 3, digest. Every successful payment, paid invoices, and trial ending reminders.

Tier 1 Stripe events that should interrupt you

For these events, a fast response changes the outcome. Miss one for a day and you can lose money or a deadline. Send them to a channel you watch.

Disputes: charge.dispute.created

A dispute has a response deadline, so send charge.dispute.created to someone who will open Stripe quickly. In the US, Stripe's dispute fee is $15 and is not returned if you win. A separate fee can apply when you counter the dispute. The deadline to submit evidence depends on the card network and the case. See the Stripe dispute alerts guide.

Failed payments: payment_intent.payment_failed and invoice.payment_failed

For subscriptions, watch Stripe's `invoice.payment_failed`. It can fire with no failed PaymentIntent, for example when an invoice has no payment method. ChargeBell alerts on payment_intent.payment_failed, which covers failed subscription attempts and one-off payments. Send that alert to an owner, and use Stripe Workflows or another tool for invoice-only failures. See the failed payment alerts guide and the Stripe decline codes cheat sheet.

Failed payouts: payout.failed

A payout can show as paid and later change to failed, usually because your bank returned it. payout.failed deserves its own alert because money you expected is not coming until you fix your bank details in Stripe.

Tier 2 Stripe events to read the same day

These do not need to wake you up, but you should see them the same day in a shared channel. They show who is joining, who is leaving, and where money moved.

• customer.subscription.created. A new subscription, which may be trialing or incomplete. MRR appears when it can be calculated, so check whether the payment succeeded.
• customer.subscription.deleted. A subscription ended. Watch the trend more than each one.
• charge.refunded. Money going back to a customer. Support usually needs this more than founders. See Stripe refund alerts in Slack.
• Large payments. A payment over a threshold you set, $1,000 by default.
• customer.subscription.updated. ChargeBell alerts on supported price changes, with the MRR change when the price data allows. Quantity changes on the same price need separate monitoring.

These events belong in a shared channel because different people act on them. Support handles a refund. A founder follows up on a cancellation. The whole team can see a new subscriber. To set this up, read which Stripe alerts go to finance, support, and founders.

Tier 3 Stripe events for a daily digest

Every successful payment, payment_intent.succeeded and charge.succeeded, is a Tier 3 event, and so is invoice.paid. These events matter as a total. Ten payments a day make a nice ping, but a thousand make a channel nobody reads. Put them in a daily digest with yesterday's revenue, payment count, new subscribers, and refunds in one message.

customer.subscription.trial_will_end fires three days before a trial ends. That is a chance to collect a payment method, but most founders handle it with product emails instead of a Slack ping. Turn it on only if trial conversion drives your business.

The founder's shortlist of Stripe events

Use this table when you set up alerts. Stripe's own options are the Dashboard, account emails, and the Stripe app for Slack through Stripe Workflows. A custom webhook or an automation tool can cover events ChargeBell does not map. For response steps, see the dispute, failed payment, and subscription guides.

How to avoid too many Stripe alerts

Two things make Stripe alerts noisy. Stripe delivers webhooks at least once, so the same event can arrive more than once. One checkout can also fire several events, such as a payment, a new subscription, and an invoice. Without deduplication, one customer action turns into three or four messages.

These rules keep the channel readable:

1. Turn on only the events you act on. If you never respond to trial reminders in real time, leave them off.
2. Set a minimum payment amount so small charges go to the digest.
3. Route by tier and team. Send critical alerts to a channel you watch, wins to #wins, and refunds to support.
4. Use quiet hours so routine alerts wait until morning while disputes and failures still post.
5. Deduplicate on the Stripe event ID and post one message per checkout.

For more, read how to avoid noisy Stripe notifications.

Stripe's own alerts vs a Stripe Slack integration

Stripe offers account emails and the Stripe app for Slack, which uses Stripe Workflows to post events to channels you choose. Emails are simpler to set up. Workflows need you to set up triggers, conditions, and message templates. ChargeBell adds routing, quiet hours, and digests for the events it supports.

You can also build your own webhook handler. It needs an HTTPS endpoint, signature checks, duplicate handling, and API calls to look up customer details. That is real engineering time. ChargeBell's Stripe Slack integration does the routing, urgency levels, and noise control without code. To compare the options, read how to monitor Stripe without checking the dashboard.

How the tiers map to ChargeBell alert types

ChargeBell maps a fixed set of Stripe events to alert types and builds some alerts from payment history. It does not map invoice.payment_failed. Payment failed and dispute created alerts are critical, so they skip quiet hours and can add an @channel mention. Other alert types follow their own routing and timing.

• payment_intent.payment_failed becomes the payment failed alert, which is critical. A payment recovered alert follows when a later charge succeeds after a recent failure.
• charge.dispute.created becomes the dispute created alert, which is critical.
• payout.failed becomes payout failed, and payout.paid becomes payout paid. Check your bank before you count the money as deposited.
• customer.subscription.created becomes new subscriber, and customer.subscription.deleted becomes subscription canceled. Both show MRR when it can be calculated.
• refund.created and charge.refunded become refund sent, and payment_intent.succeeded becomes payment received. Fee and net appear when the data and your display setting allow.

Every alert above is on by default except invoice paid, trial ending, and first-time customer. Those are off because they often repeat other alerts. ChargeBell sends one alert per event. When several could fire, it picks the most specific one in this order: payment recovered, large payment, first-time customer, then payment received. A payment that failed and then succeeded is labeled "recovered" instead of posting twice. For subscriptions, see Stripe subscription alerts in Slack.