# What is Changelog?

A changelog is the running log of changes a software product or codebase ships over time, typically organized by version or release date and grouped by change type (features, improvements, fixes, security, deprecations). It serves as both an engineering reference and a customer-facing communication channel — the same content often appears in a `CHANGELOG.md` file in the repo, on a hosted product page, and in subscriber emails.


## Example

Stripe's [API changelog](https://docs.stripe.com/changelog) and Linear's
[public changelog](https://linear.app/changelog) are two well-known
examples — both list changes chronologically with version numbers, group
items by category, and write entries from the user's point of view rather
than as raw commit messages. A `CHANGELOG.md` file in an open-source repo
(the [Keep a Changelog](https://keepachangelog.com) convention) is the
developer-internal version of the same idea.

## Why it matters

A maintained changelog is the most direct way a product communicates "we
shipped this, here's what changed" to the people who use it. Without
one, users discover changes accidentally, support gets repetitive
questions about features that already exist, and releases stop feeling
like progress. With one, the changelog compounds — it doubles as
marketing surface, SEO content, and a record of velocity over time.

## More context

A well-maintained changelog accomplishes four things at once:

1. **Tells your users what changed.** Without it, every release is invisible to the people who'd benefit.
2. **Builds trust over time.** An active changelog signals that the product is alive and that ships keep happening.
3. **Reduces support load.** "When did you ship X?" stops being a support ticket if the answer is two clicks away.
4. **Becomes a marketing asset.** Search engines index it, prospects evaluate it, and customers reference it.

The distinction between a developer's `CHANGELOG.md` (terse, version-keyed, written for other engineers and downstream library users) and a customer-facing product changelog (richer, user-focused, branded) matters: the same release event usually warrants both, written for different audiences. Tools like [Herald](/) draft the customer-facing version automatically by reading your merged GitHub PRs — so the engineering-side history (`CHANGELOG.md` or [GitHub Releases](/compare/github-releases/)) and the customer-side hosted page stay in sync without copy-paste.

For the practical "how to write one well" piece, see the [release notes guide](/blog/how-to-write-release-notes/). For the difference between a changelog and release notes specifically, see [changelog vs release notes](/glossary/changelog-vs-release-notes/).

## Related terms

- [Release Notes](/glossary/release-notes/)
- [Changelog vs Release Notes](/glossary/changelog-vs-release-notes/)
- [Conventional Changelog](/glossary/conventional-changelog/)
- [Conventional Commits](/glossary/conventional-commits/)

Deeper guide: [How to write release notes users actually read](/blog/how-to-write-release-notes/)

Category: Changelog Fundamentals
Last reviewed: 2026-05-28