Most changelogs die the same way. The product keeps shipping, but the changelog is a manual step at the end of a release — a separate page, a separate login, a separate writing session that nobody schedules. So it slips. Three weeks after launch it's already stale, and a stale changelog is worse than none: it tells your users you stopped shipping.
The fix isn't more discipline. It's removing the step. Your commits and release tags already describe what changed. The changelog should fall out of the pipeline you already run, not sit in a tool you have to remember to open.
This post shows how to publish a changelog entry on every release, straight from a GitHub Action.
The idea: the release is the trigger
You already cut releases. Maybe you tag v1.4.0 and let GitHub generate release notes from merged PRs. Maybe you run npm version and push a tag. Either way, the moment a release exists is the exact moment your users should hear about it.
So wire the changelog to that moment. When a release is published, an Action reads what changed, drafts a clean entry, and publishes it — to your hosted page, your embedded widget, your RSS and JSON feeds, and an email digest to your subscribers. One event, every channel. No dashboard detour.
The minimal setup
Two things up front: an API key and a workflow file.
Create an API key in your DeployLog dashboard under Settings → API keys, and add it to your repository as a secret named DEPLOYLOG_API_KEY (Settings → Secrets and variables → Actions). Never paste a key into the workflow file itself.
Then add this workflow:
name: Publish changelog
on:
release:
types: [published]
jobs:
changelog:
runs-on: ubuntu-latest
steps:
- uses: deploylogdev/action@v1
with:
api-key: ${{ secrets.DEPLOYLOG_API_KEY }}
project: my-app
ai-summarize: true
That's the whole thing. On the next published release, the Action takes the release name and notes, runs them through ai-summarize to produce a titled, categorized entry, and publishes it to the my-app project.
ai-summarize is optional. Turn it off and the Action publishes your release notes as-is — useful if you already hand-write tight notes and just want them fanned out to every channel.
What "drafts a clean entry" actually means
Raw release notes are written for the repo. They read like:
* Bump next from 16.2.8 to 16.2.9 by @dependabot
* Fix race in widget theme resolution (#17)
* Add dark mode to the public changelog page (#21)
* chore: tidy eslint config
Your users don't need three of those four lines. ai-summarize (Claude Haiku, under the hood) collapses the noise into something a human wants to read:
## Dark mode and a steadier widget
*Improvement · June 23, 2026*
The public changelog page now follows your system dark-mode setting, and the
embedded widget resolves its theme more reliably on first paint. Dependency
and tooling updates round out the release.
It's a draft, not an autopublish-and-pray. You review entries in the dashboard before they go live if you want a human in the loop — or let trusted releases publish straight through. Your call per project.
Prefer the CLI? Same engine, your terminal
The Action is the CLI wearing a CI hat. If you'd rather publish from a release script — or just try it before committing a workflow — the same command runs anywhere:
deploylog push --from-git --ai-summarize
--from-git reads your recent commits instead of a GitHub Release, which is handy for projects that ship from main without formal tags. Same drafting, same fan-out to page, widget, RSS, and email.
Why this beats the dashboard habit
A changelog you publish by hand competes with everything else at the end of a release, and it loses. A changelog that publishes itself from CI has no competition — it happens whether or not anyone remembers.
That shift does three things:
- It stays current. The changelog is exactly as fresh as your last release, automatically.
- It removes the bottleneck. The person who merged the work ships the entry. No handoff to whoever owns the marketing page.
- It reaches everyone at once. Page, widget, RSS, JSON, and email all update from a single release event.
The discipline of "write the changelog every week" is hard because it's a separate habit. The discipline of "cut a release" you already have. Hang the changelog off the habit that already sticks.
DeployLog is a changelog and release notes platform for developers. Publish from the CLI, a GitHub Action, or the dashboard — and reach users through an embeddable widget, RSS, JSON, and email digests. Free for one project, no credit card. Start free with GitHub →