Here is a secret about the changelog you haven't written: it already exists.
Open your repo and run git log --oneline for the last two weeks. Every shipped feature, every fix, every breaking change is in there, dated, attributed, in order. You wrote it while you worked, without thinking of it as writing. The changelog is done.
It's just written for the wrong reader.
Two audiences, one log
A commit message is written for someone with the codebase open. It names files, functions, and internal systems, because that's what the next maintainer needs:
fix: retry Stripe webhook on 429 with backoff
feat: bulk CSV export on billing settings
fix: race in subscriber confirm token check
chore: bump next to 16.2.3
refactor: extract digest send into lib/email
Your users need none of that vocabulary and all of that information. The same two weeks, written for someone who uses the product instead of maintaining it:
## Billing exports, and a fix for missed payment updates
*Feature*: Export your billing history to CSV from Settings.
*Fix*: Payment status updates could be delayed when our payment
provider rate-limited us. They now retry automatically.
Nothing was invented. The chore and the refactor were dropped, the two entries that affect users were kept, and each one was rewritten from "what changed in the code" to "what changed for you." That's the entire job. Not authorship. Translation and filtering.
Why the translation doesn't happen
If the work is that small, why do most changelogs sit three months stale?
Because the translation comes due at the worst possible moment. You just shipped. The PR is merged, the deploy is green, and your head is already in the next thing. Opening a CMS to write prose about the thing you just finished is a context switch nobody volunteers for, so it gets deferred, and deferred changelog entries don't get written late. They don't get written.
The fix is not discipline. The fix is moving the changelog into the path you're already on: the terminal where you just deployed, or the CI pipeline that cut the release.
From git log to published entry
This is the workflow DeployLog is built around. From the terminal, one command reads your commits since the last entry and drafts the changelog for you:
deploylog push --from-git --ai-summarize
The --from-git flag collects the commit messages. The --ai-summarize flag rewrites them into a titled, categorized entry in user language: chores and refactors filtered out, the Stripe retry translated into a sentence about payment updates. You review the draft, edit what the model got wrong, and publish. The writing moment shrinks from "open a CMS and compose" to "read a draft and approve."
If you'd rather never leave CI, the GitHub Action does the same on every release:
- uses: deploylogdev/action@v1
with:
api-key: ${{ secrets.DEPLOYLOG_API_KEY }}
project: your-project
ai-summarize: true
Publish a GitHub release and the changelog entry drafts itself from the release notes.
Keep the judgment, automate the chore
A fair objection: shouldn't a human write the thing users read?
Yes, and one still does. The model produces a draft, not a publication. Entries created this way arrive as drafts by default; nothing reaches your users until you've read it. What the automation removes is the blank page and the context switch, which are the two things that actually kill changelogs. What it keeps is your judgment about what ships and how it's phrased.
In practice the review takes under a minute, because the draft is usually right about the what and only occasionally wrong about the emphasis. Compare that to the alternative you've been living with: a perfectly accurate log of everything you shipped, visible to no one who pays you.
The reframe
Stop thinking of your changelog as a writing task you're behind on. You are not behind on writing. You've been writing it all along, one commit at a time. You're behind on publishing, and publishing is the part machines are good at.
Your commits already tell your product's story. Publish it.
DeployLog is a changelog and release notes platform for developers. Post from the dashboard or the CLI, reach users through an embeddable widget, RSS, JSON, and email digests. Sign up with GitHub