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.
Top comments (1)
Writing commit and PR titles for a reader is the habit that makes the weekly note almost free. A small convention helps the filtering step too: start titles for customer visible changes with something like "user:" and leave refactors unmarked, so the weekly list sorts itself and you're only editing, not hunting. For changes to a screen, one line is often not enough to tell someone where to look. A small screenshot of the new screen, or a link to a few seconds of it in use, next to that line saves the reply asking where the new option went. Sending it from your own name makes those replies more likely too.