The short version
- The email goes to the people who voted for what shipped, and nobody else.
- Put the change in the subject line, in the words the person used when they asked.
- Leave out the parts of the release that aren't about this reader, which is usually most of it.
- When nothing shipped, send nothing. The silence is honest.
A release notes email example is worth reading only if it answers who the message goes to, because the email itself is the message that tells somebody a thing they wanted now exists. Most of them fail on the second word of that sentence, because they're sent to everybody rather than to somebody.
Here's one written out in full, then the two decisions behind it that matter more than the writing.
What does a release notes email look like?
Short, specific, and addressed to a person who already knows what the feature is.
Subject. The tag filter you asked for is live
You voted for tag filtering on the public board in March. It shipped this morning.
Added. Filter any board by one tag or several. The filter is in the address, so a filtered board can be linked. Improved. The board remembers the last filter you used for the rest of the session. Fixed. Boards with more than five hundred requests no longer lose their sort order when a filter is cleared.
The request you voted for is here, with the discussion that shaped it.
If this is not what you meant, reply to this message. That is a faster route to a correction than filing a second request.
Six sentences and three lines of substance. Every one of them is a fact about a change, and the only sentence that's not is the one inviting a correction.
Want these published and delivered rather than written and forgotten? Ten changelog tools, checked on their own sites for email, a feed and a widget.
Why is it addressed to one person's vote?
Because the person who asked is the only person for whom this is news, not noise.
The rule this product follows is that a release email goes to signed in voters whose own vote is in that release, and to no one outside that list.
If a release closes three requests, the email reaches the people who voted for those three requests. There's no mailing list, because a mailing list is the thing that turns a release note into marketing.
The effect is uncomfortable to look at the first time. A release that closes one small request emails eleven people. A general announcement would have emailed four thousand.
The eleven open it, because it's about a thing they personally asked for, and the four thousand learn to archive anything from you on sight. How the sending rule works here's written up with the feature.
What goes in the subject line?
The thing that changed, in the words the person used when they asked for it.
The three subject lines that fail are the ones that describe the release, not the change. Version 2.4 is out tells a reader nothing. Product update, September tells them less. What's new this month tells them there's homework.
The one that works names the thing. The tag filter you asked for is live isn't a clever subject line, and it doesn't need to be, because the reader recognises their own request in it.
If a release closes several unrelated requests, that's several emails to several groups, not one email trying to be about all of them.
What should be left out of the email?
The parts of the release that aren't about the reader, which is usually most of it.
A release contains internal work, infrastructure changes and fixes nobody outside the team could describe. All of that belongs in the full changelog, where somebody who wants the complete list can read it.
It doesn't belong in a message written to one group of people about one thing. Which categories of entry exist, and which audience each belongs to, is set out separately.
The second thing to leave out is the ask. A release email that ends by requesting a review, a share or an upgrade has spent the goodwill of the one moment when a customer is pleased with you. Tell them the thing shipped, link the request, and stop.
How often should release emails go out?
As often as releases close requests, which for most teams is less often than they think and more often than they do.
Sending on a fixed monthly schedule produces a digest, and a digest is a different document with a different job. It's read by people who want an overview, it's not addressed to anybody in particular, and it's fine.
What it can't do is the thing described above, because by the time the monthly edition goes out, the person who asked in March has forgotten they asked.
The practical arrangement is both, with the per request message going out when the request closes and the digest going out on whatever rhythm you can sustain. The template for the digest half is on this site as a file you can take.
What does this look like when nothing shipped?
You send nothing, and the silence is honest.
Our own changelog has one release on it, dated 29 April 2026, and we have shipped plenty since. The work went out without cards moving to the completed column on the public board, so the changelog stayed quiet and no emails went anywhere.
The whole story is on our own changelog page, including why we would rather publish that than tidy it up.
A changelog built out of the board only moves when the board moves. That's the cost of the design, and it's also the only version of a changelog that can't be faked by somebody whose job is tidiness.
14 days, a card at signup, then $9 or $39 a month.
