customer.subscription.deleted: email a customer when Stripe ends it

Michael Fall — Sat, 07 Nov 2026 00:00:12 +0000

You have a paying customer whose subscription has just ended, and Stripe has sent one event and nothing else. The event doesn't say whether they chose to leave, and that matters, because someone whose card kept failing never decided anything, and a "sorry to see you go" note is the wrong thing to send them. The few who did choose to leave are worth one short email asking why, and their reply is where you learn something. The guide below shows when Stripe sends the event, how to read its reason, and the email I would send.

The short answer

When a subscription ends, Stripe sends an event called customer.subscription.deleted. It is the moment a paying customer stops being one, and the best thing to send is short: say it has ended, ask why in one line, and leave the door open.

The event on its own, with the fields worth reading, is on the customer.subscription.deleted page.

When Stripe sends it

It depends on how the subscription was cancelled.

At the end of the period. Most cancel buttons, Stripe's customer portal included, cancel at the end of the period the customer already paid for. Stripe sends customer.subscription.updated with cancel_at_period_end set to true when they press it, and customer.subscription.deleted when the period runs out.
Straight away. A subscription cancelled at once sends customer.subscription.deleted right away.
After failed payments. If payments keep failing and your Stripe settings cancel the subscription when retries run out, it ends the same way, with cancellation_details.reason set to payment_failed.

That last one matters. Somebody whose card expired never decided to leave, and "sorry to see you go" is the wrong email for them. Check the reason before you send anything.

Your own webhook

Add a webhook endpoint in Stripe that listens for customer.subscription.deleted.
Check the signature on every request. Stripe signs each one in a Stripe-Signature header and needs the raw body untouched.
Return a 2xx fast and send the email after. Keep the event ids you have handled, because an event can arrive twice.

const event = stripe.webhooks.constructEvent(rawBody, signature, endpointSecret);

if (event.type === "customer.subscription.deleted") {
  const subscription = event.data.object;
  const reason = subscription.cancellation_details?.reason; // "cancellation_requested", "payment_failed", ...
  const customer = await stripe.customers.retrieve(subscription.customer as string);
  // customer.email, customer.name
}

The subscription carries the customer's id rather than their email, so fetch the customer. If your portal asks why they're leaving, cancellation_details.feedback and cancellation_details.comment hold the answer, and your email shouldn't ask again.

What the email should say

Keep it to a few lines, from you, with nothing to sell.

Subject: Your [your app] plan has ended

Hi {{first_name}},

Your [your app] plan has ended, and you won't be charged again. Your account and everything in it is still here if you come back.

Could you tell me why you left? One line is plenty, and you can reply to this email.

[Your name]

The reply is the useful part. A cancellation survey email template has more ways to ask, and win-back emails cover what to send weeks later.

FAQ

Is customer.subscription.deleted the same as a cancellation?

It's the end of the subscription. A customer who cancels at the end of the period has cancelled before this event arrives, and is still paying until it does.

Should I email when they press cancel, or when it ends?

When it ends is the safer default, because it's when the change is real. You can also send a short "got it" when they press cancel and keep the question about why for when it ends.

What if a failed payment ended it?

Send the failed payment email instead, with a way to update the card. That customer may want to stay.

This article was written with the help of AI.

Changelog email: turn your Vercel deploys into a product update

Michael Fall — Sat, 31 Oct 2026 01:00:10 +0000

Every production deploy you ship is a small piece of news for the people using your app, and most of them never hear it. I'd gather a week of deploys, keep the changes a customer would notice, and send one short note from my own name instead of an email on every push. The lines for that note can come from the commit and pull request titles, so it helps to write those titles for a reader. The article below walks through the Vercel side, the plain way to do it by hand, and what the email should say.

The short answer

Do not email people on every deploy. Gather a week of them, pick what a customer would notice, and send one short update to the people who asked to hear from you.

The plain way

Once a week, open your Vercel deployments, or run git log, and look at what went to production.
Keep the changes a customer would notice. Drop the refactors and the fixes nobody saw.
Write three or four lines in plain words.
Send them to a list of people who agreed to get product updates.

Vercel can call a webhook of yours when a deploy succeeds. Its events include deployment.succeeded, and the payload says whether the target was production. As of October 2026, Vercel's account webhooks are on its Pro and Enterprise plans. A webhook is handy for collecting deploys in one place, but you still choose the words.

The hard part is not the sending. It is remembering to do it, every week, while you are busy building.

What the email should say

Lead with what changed for the reader, in their words, and keep it short.

Subject: What's new in [your app]

Hi {{first_name}},

This week we shipped:

[Date]: [what changed, in a customer's words]

[Date]: [what changed, in a customer's words]

Something you wish we would build next? Reply to this email.

[Your name]

More in product update emails and the product update email template.

FAQ

Does every deploy send an email?

No. Only the list's scheduled email goes out, and a week with nothing deployed sends nothing.

Do I need GitHub?

No. Without it the lines come from each deploy's title, the first line of its commit message. GitHub adds the pull request titles.

This article was written with the help of AI.

DEV Community: Kicklace

customer.subscription.deleted: email a customer when Stripe ends it

The short answer

When Stripe sends it

Your own webhook

What the email should say

FAQ

Is customer.subscription.deleted the same as a cancellation?

Should I email when they press cancel, or when it ends?

What if a failed payment ended it?

Changelog email: turn your Vercel deploys into a product update

The short answer

The plain way

What the email should say

FAQ

Does every deploy send an email?

Do I need GitHub?