How to Monitor Stripe Subscriptions in Slack

To monitor Stripe subscriptions in Slack, you need three things Stripe doesn't hand you: a way to tell an upgrade from a downgrade from a cancellation, a monthly-normalized MRR number for each change, and a channel where the whole team can see it. Stripe fires one raw customer.subscription.updated firehose for almost everything — no upgrade event, no cancel event, no MRR figure. This guide covers which events actually matter, the gotchas that trip people up, and how ChargeBell turns each change into a plain-English Slack alert with a signed MRR delta on every message.

The four subscription events you actually care about

Stripe emits a handful of subscription-lifecycle webhooks, but only four map cleanly to the moments a SaaS operator cares about. The rest are variations on these.

• `customer.subscription.created` — a new subscription. Note it may arrive with status incomplete if you use payment_behavior=default_incomplete, so a brand-new sub isn't always immediately paying.
• `customer.subscription.updated` — any change at all: a plan switch, a coupon applied, a status flip, or a cancel_at_period_end toggle. This is the firehose. Everything interesting and everything boring arrives here.
• `customer.subscription.trial_will_end` — advance notice, sent exactly 3 days before trial_end (or immediately if the trial is shorter than 3 days). Your cue to remind the customer to add a card before the trial converts.
• `customer.subscription.deleted` — the subscription has fully ended. canceled is a terminal state that can't be updated, so this is your signal to revoke access.

Two more show up if you use pause behavior: customer.subscription.paused (a trial ends with no payment method and trial_settings.end_behavior.missing_payment_method is set to pause, so invoicing stops) and customer.subscription.resumed (a card gets attached and billing un-pauses). Most teams can start with the four above. If you're deciding the full set to watch, see what Stripe events a founder should monitor.

Why raw subscription webhooks are painful to read

Here's the catch: there is no `upgrade`, `downgrade`, or `cancel` event. All three arrive as customer.subscription.updated, and it's on you to tell them apart. Every payload carries an object (the new state) and a previous_attributes object (only the fields that changed, with their old values). To know what really happened, you diff one against the other.

• Real plan change vs. noise — a price change shows up inside previous_attributes. If the price didn't change, the updated event is probably just a metadata edit or a status flip, not something worth a Slack ping.
• Upgrade vs. downgrade — compare the old price against the new one. Higher is an upgrade (expansion MRR), lower is a downgrade (contraction MRR). There's no flag; you compute the sign yourself.
• Trial outcome — a trial ending arrives as a status transition: trialing → active (converted), trialing → canceled (churned), or trialing → past_due/incomplete (payment failed). Same event, very different meaning.

There's a config trap too: `trial_will_end` has to be added explicitly to your webhook endpoint's event list in the Stripe Dashboard (Developers → Webhooks). A generic "all subscription events" selection commonly misses it, so trial reminders silently never fire. This is one of many reasons founders eventually stop maintaining their own handler — see ChargeBell vs. custom Stripe webhook code.

The MRR math Stripe makes you do yourself

Stripe never tells you the MRR impact of a change — it just reports raw amounts on whatever billing interval each price uses. To get a comparable monthly number you have to normalize every item:

• Yearly amount ÷ 12, weekly amount × 4, daily amount × 30, monthly × 1.
• Divide by interval_count (a price billed every 3 months isn't the same as monthly).
• Multiply by item quantity — forget this and a 5-seat plan under-reports by 80%.
• Subtract discounts — line items show amounts before coupons, and one-off (non-subscription) line items must be filtered out entirely.

Get this right and a subscription change slots into one of five MRR-movement buckets: New (new customers), Expansion (upgrades and add-ons), Contraction (downgrades), Churned (cancellations), and Reactivation. Net new MRR = New + Expansion − Contraction − Churned. Tracking the buckets tells you not just *whether* MRR moved but *why*. (Historical MRR from raw Stripe data is famously fiddly — the subscription object only holds current state, so you can't reconstruct past price changes from it alone.)

How ChargeBell helps you monitor Stripe subscriptions in Slack

ChargeBell does the diffing and the monthly normalization for you, then posts a plain-English Slack alert with a signed MRR delta on every subscription message. It reads the same webhooks described above through official read-only Stripe Connect OAuth — it can see subscription events but can never move money or change anything. Its subscription alert catalog maps exactly to the four moments that matter:

• 🎉 new_subscriber — a new paid subscription. The MRR delta is the new monthly amount (positive). On by default.
• ⬆️ plan_changed — a price or quantity change. The delta is the signed difference "per month, effective today," and the title auto-reads *Plan upgraded* or *Plan downgraded* from the sign. On by default.
• 😕 subscription_canceled — the subscription ended. The delta is the lost monthly amount (negative). On by default.
• ⏳ trial_ending — advance notice a trial is about to convert, so you can nudge the customer to add a card. Off by default — flip it on if you run trials.

The delta is normalized to monthly using the same year ÷ 12, week × 4, day × 30, times-quantity method above — so the number on the alert is the real MRR impact, not a raw price. Here's what a new subscriber looks like in Slack:

And a plan change, where the signed delta tells the whole story at a glance:

Cancellations and trial reminders land the same way — a lost-MRR figure on the churn, and a dated heads-up before a trial converts:

Every message carries a deep-link back to the exact Stripe object, so a one-line ping in Slack is one click from the full record. That per-event, per-object precision — with the MRR delta inline — is the core difference from generic recipes and metrics dashboards. For the money-in side of the same feed, see how to get Stripe payment notifications in Slack.

Set it up in about two minutes

1. 1

   Create your account

   Sign up at app.chargebell.com — no card needed on the free plan.

2. 2

   Connect Stripe

   One-click, read-only OAuth. ChargeBell sees subscription events and can never move money or edit anything in your account.

3. 3

   Connect Slack

   Add the app and pick a channel — send wins to #wins and churn to #founders if you like. It only posts to channels you choose.

4. 4

   Turn on the subscription alerts

   new_subscriber, plan_changed, and subscription_canceled are on already. Toggle trial_ending on if you run trials.

5. 5

   Send a test alert

   Confirm it works before your next real subscription change lands. You'll get your first alert before your coffee cools.

A weekly digest for MRR movement

Per-event alerts are great for the moment something happens, but you also want the shape of the week. ChargeBell's weekly digest sums the stored MRR delta from every delivery into New MRR (new subscribers), Upgrade MRR (positive plan changes), and Churned MRR (all negative deltas), then reports a Net change and a "biggest win" line for the largest single positive mover:

It also caches a live MRR and active-subscriber snapshot for your org. Digests are part of the Pro plan; on the free plan you still get every subscription alert in real time, up to 100 alerts a month with 7 days of history.

ChargeBell vs. a free metrics dashboard

The most direct comparison for "MRR movements in Slack" is ProfitWell Metrics (now maintained by Paddle). It's genuinely strong and 100% free: it posts real-time Slack notifications for new signups, upgrades, downgrades, cancellations, and failed payments, lets you pick notification types, adjust frequency, and filter by transaction size — plus full revenue dashboards (MRR, churn, LTV) beyond the alerts. Setup is a few clicks. Here's an honest side-by-side:

ProfitWell is excellent if you primarily want a free metrics dashboard with occasional Slack summaries. ChargeBell is the better fit if you want a precise, per-subscription-event Slack feed with the MRR delta and a Stripe link on every message. Generic Zapier "Stripe → Slack" recipes can send the events too, but you'd build the MRR normalization and upgrade/downgrade detection yourself — more on that in ChargeBell vs. Zapier.