A changelog tool for SaaS releases is the easiest part of this product to build and the easiest part to make pointless. Anybody can publish a list of what shipped. The question that decides whether it does anything is who finds out.
Most tools in this category answer that with a subscriber list. Somebody clicks follow, they go in a list, and every release goes to the whole list. Ours does something narrower and it is the reason this page exists.
Where do the entries come from?
From the board, and you do not write them twice.
A release is a group of features that reached the Completed column. Shipping behind a feature flag moves when that column becomes true, so the changelog follows the column rather than the deploy.
When you publish it, the cards in it become the entries. The heading a person voted on is the heading they read about later, in the same words, because it is the same record.
That is the whole mechanism. There is no separate changelog editor to keep in sync with your roadmap, because there is no second copy to keep in sync.
Release management is the wider practice this sits inside, and the changelog is the part of it a customer ever sees. If you are working out what a changelog owes a reader that release notes do not, that is a different question and it has its own page.
If this is the part you came to check, start a trial and turn it on. 14 days, a card at signup, then $9 or $39 a month.
Who gets told when you publish?
The people whose own vote is in that release.
When a release is published the code collects the completed features in it, finds the votes on those features, and keeps only the votes cast by a signed in user. Then it writes to each of those people, naming the headings they personally voted for.
Three things follow from that and all three matter.
Somebody who voted anonymously gets nothing, because there is no address to write to. Somebody signed in with no email on their account gets nothing either, and the code skips them rather than failing.
Somebody who voted for two things in the same release gets one email naming both, not two emails.
And a release is claimed before anything is sent, so a release that has already been announced cannot be announced twice, even if the publish is triggered again.
Two limits sit on top of all of that and they belong here rather than in a footnote. A recipient can switch release emails off for themselves, and it is silent from your side because nothing bounced.
And any one address takes at most one product email a day from us across everything we send, so a person who already heard from your board that morning does not get this one, and it is not tried again tomorrow.
The wider question of what a release note is for, and why the published page matters more than the email, has its own page.
The step this replaces has a name, and it is the part of a customer feedback loop that almost nobody builds.
Why not just build a subscriber list?
Because a subscriber list answers a different question, and it is a worse one.
A follow button collects people who like your product enough to click a button. A vote collects people who wanted one specific thing. When you ship that thing, the second group has a reason to open the email and the first group has a habit to break.
There is a real cost to this and we are not going to hide it. A subscriber list is bigger.
If your goal is the largest possible announcement, a broadcast tool is the right purchase and several of them are built for exactly that. What you get here instead is a smaller message that is always about something the reader asked for.
Is there an RSS feed?
No. There is no RSS feed and no Atom feed anywhere in the product today.
That is a real gap and it is worth stating plainly rather than burying. A feed is the one way somebody can follow your releases without giving anybody an email address, and several tools in this category ship one.
We are not going to put a date on it here, because a page that promises a feature by a month is a page that quietly becomes wrong. If it matters to you, it is the sort of thing our own roadmap is for.
What does a visitor actually see?
A page of releases, newest first, each with its date and the features it contains.
Beside every one of those features is how many people asked for it. That is the sentence worth stopping on, because it is the thing a changelog built on a separate editor cannot print.
We added scheduled exports is an announcement. We added scheduled exports, and 34 people asked for it, is an answer, and the only reason the number is there is that the vote and the release are the same record.
Each shipped item can carry a type as well, so a reader scanning for the breaking change finds it without reading the prose. A release can also be marked featured, which the page draws differently from the rest.
The whole thing takes your board's colours, fonts and corner radius, because it reads the same settings the board does. There is nothing separate to style.
Every release also has its own address, built from its name, lowercased, with any run of other characters turned into a single hyphen and any trailing one removed.
So a release called Autumn Cleanup 2026 lives at a readable address you can paste into a support reply, and it keeps working after you publish the next one.
How are the views counted, exactly?
Per release, on the release's own page, once per address every thirty minutes.
That sentence is deliberately more careful than the one that used to be here, which said once per visitor. It is not per visitor. The count is keyed on the caller's network address, so an office, a school or anywhere else behind one shared address counts once for everybody who reads it that half hour.
Two more things follow from how it is done. The record of who has been counted lately is held in memory rather than in the database, so restarting the application clears it and the same reader can be counted again.
And the increment happens on a single release page, so somebody who scrolls the whole changelog without opening one adds nothing to any of them.
None of that makes the number useless. It makes it a floor rather than a measurement, and a floor is worth having as long as you know that is what you are reading.
Does it need an account to read?
No. The changelog is public, like the board and the roadmap, and a visitor needs nothing to read it.
The account only matters at the other end. Reading is open to anybody, and being told about a release requires having been signed in when you voted, because that is where the address comes from. What that email looks like, written out in full, is on its own page.
Can I put it inside my own product?
Yes. The changelog widget draws the same releases inside your own page with one script tag, documented with the call and its options, and it is not held back for the higher plan, so it works on the nine dollar plan along with every other widget.
That is usually the better placement. A changelog on a marketing site is read by people who came looking. A changelog inside the product is read by people who are already using the thing that changed. The same release written for a store listing and for the inside of an application is worked through separately.
This suits a team whose releases come off a board they already keep. A team that writes long launch posts for people who do not use the product yet wants a blog or an announcement tool instead, and Headway is a changelog and nothing else if the announcement is the whole job.
What this is not
It is not a marketing announcement tool. There is no scheduling, no audience segmentation and no campaign reporting, and if those are what you need then a purpose built announcement product will serve you better.
It is not a blog. Entries are features that shipped, not essays, and they are as long as the card was.
14 days, a card at signup, then $9 or $39 a month.
Where to see a real one
Our own changelog runs on this, and it is built the same way yours would be. Every entry there started as a card somebody voted for.