Changelog

A changelog board is a public feed of what you shipped. Entries are drafted, then published, and can be embedded directly in your product.

​

Entries

Each entry carries a title, a slug, a body, labels, and a published date. Entries are created and edited as drafts, then published as a separate step — so an entry can be written ahead of a release and go live when the release does.

​

One Board or Several

Changelog boards are boards, so you can run more than one. Separate feeds per product line — a desktop app, a recorder, a mobile client — keep each audience’s feed relevant. Each gets its own name and slug.

​

Embedding the Feed

To display the full changelog board on your own website, follow Embed and Domain Setup. The guide includes the script, DNS and HTTPS instructions, and browser checks for a subdomain or website path. A changelog board can be embedded in your own application with a public board key. The embed gives you:

• A lightweight what’s-new badge and release feed
• Unread tracking, so returning users see what’s new since their last visit
• Isolated styling, so the widget doesn’t inherit or fight your CSS

​

Changelog as an Input, Too

Your published changelog is also a source BuildBetter reads:

• Releases / Close the Loop ingests changelog entries alongside GitHub releases and RSS to build the shipped-feature catalog.
• Knowledge Gaps checks those same releases against your documentation.

So writing a substantive entry does double duty: customers read it, and BuildBetter uses it to match shipped work back to requests and to find documentation that fell behind.

​

Publishing vs Telling

Publishing an entry is a broadcast. It does not tell the customer who asked for that specific feature — see Close the Loop for the individual follow-up.

​

Next