Plenty of companies have a changelog. Linear is one of the few whose changelog people follow for fun. This teardown looks at what linear.app/changelog actually does and at the reasoning Linear published about it. It is not a Steperly customer story: we're not affiliated with Linear, and everything here comes from their public site and blog, linked in the sources.
Unusually, Linear explained its approach in public. In 2020, co-founder and CEO Karri Saarinen wrote Startups, Write Changelogs, a short essay that doubles as a how-to. We'll use it alongside what the changelog looks like today.
What a Linear changelog entry looks like
Take the September 24, 2026 entry, New controls for Linear coding agent. Its structure repeats across entries:
- A dated headline naming the main change, with its own permanent URL.
- A short narrative intro that states the problem before the feature. The team-organization section in the same entry opens with why a single workspace-wide system gets hard as companies grow, and only then describes the new controls.
- Linkable sub-sections for each part of the release, shown with looping product videos rather than static marketing art.
- A pointer to the docs for details, so the changelog stays readable and the reference lives elsewhere.
- "Fixes" and "Improvements" lists, each item tagged with the product area (Editor, Diffs, Slack, iOS), so a reader can scan for the part of the product they care about.
The changelog sits under Linear's "Now" section next to product launches, team posts, community posts, and press, and it is linked from the site footer. It also has RSS and JSON feeds, so people can follow it without visiting the site.
The cadence is the strategy
The RSS feed makes the rhythm easy to check. Of the 30 most recent entries we looked at (December 2025 to September 2026), 25 were published on a Thursday; the rest landed on other weekdays, with occasional gaps of two weeks or more. Saarinen's essay explains why the schedule matters more than any single post:
Set up a schedule, like a weekly or bi-weekly cadence. Try not to slip.
He adds that Linear pairs its changelogs with its cycles (sprints), so the changelog acts as a summary of what the team achieved in that cycle. If a week has nothing to show, the essay treats that as a signal to understand why progress is slow, not as a reason to skip quietly.
Why it works: a predictable cadence turns release notes from an announcement into a habit, for readers and for the team. Readers learn to expect something; the team learns to ship something.
Who the changelog is really for
The essay lists the audiences a public changelog reaches. It reads like a marketing plan that happens to cost nothing:
| Audience | What the changelog does for them (per Linear's essay) |
|---|---|
| Early adopters | Shows that feedback is heard and the product keeps improving |
| The team | Builds momentum and a shipping culture; a first shipped feature becomes a team moment |
| Prospective users | Gets shared with co-workers and friends, including people who aren't Linear users yet |
| Candidates | Signals culture and pace; Saarinen wrote that most of their candidates had followed the changelog before applying |
| Investors | Offers public proof that the team can execute |
These are Linear's own observations from 2020, when the essay said they had published over 50 changelogs in 12 months and had more than a thousand people following the updates. We haven't independently verified those numbers, and they will have changed since. The point holds: one artifact serves five audiences.
The writing rules behind it
The most reusable part of the essay is its list of recommendations. Paraphrased, with one direct quote:
- Write for people. "Remember to write about things that are interesting to a human." A database migration only makes the cut if it improves performance or the user experience.
- Rotate the author. Usually the person who built the feature writes about it.
- Feature one to three larger changes and collect the small fixes in one section. The fixes still matter, because they show you care about small annoyances.
- Match the voice to the audience. Technical readers want more detail; others don't.
- Include screenshots or videos so people unfamiliar with the product get the gist quickly.
- Don't overthink the tool. Plain text, GitHub, Notion, or a blog all work. Linear wrote theirs in Markdown on a Next.js marketing site at the time.
- Redistribute it. Linear shared updates on Twitter and offered a newsletter subscription during onboarding, copying the changelog content into the email.
Today's changelog follows these rules closely. The headline features get narrative and video, and the dozens of small fixes sit in tagged lists below them.
A changelog entry template you can reuse
Put together, Linear's structure and the essay's rules give a template that fits on one screen. Copy it into whatever tool you write in:
- Date and headline. Name the most important change in plain words, not a version number.
- The problem, in one or two sentences. Who was stuck, and on what. Write it the way a customer would describe it.
- What changed. One short paragraph per headline feature, with a 10 to 20 second clip or a clean screenshot of the real UI.
- Where to learn more. A link to the updated help article or guide.
- Improvements. A bulleted list, each item starting with the product area.
- Fixes. Same format. Name the symptom the user saw, not the internal cause.
The link in step four matters more than it looks. A changelog tells people something changed; the docs tell them how to use it. Linear's entries point readers to the docs for detail, which keeps each entry short and gives the docs a steady stream of traffic. If you ship a feature without updating the guide, the changelog sends people to a page that no longer matches the product. That gap erodes trust faster than not announcing at all.
A practical way to close it: capture the feature once while you test it before release. The same recording can produce the changelog clip, the screenshots for the help article, and a short walkthrough video, so the announcement and the documentation ship together instead of weeks apart.
How to apply this on a small team
A changelog is one of the cheapest marketing channels a small SaaS team has, because the raw material (what you shipped) already exists. Here's a setup that takes about 30 minutes a week:
- Pick a day and publish on it. Weekly if you ship weekly, every other week if not. Put it on the calendar and treat a missed week as a question about your roadmap.
- Choose one to three headline changes. For each, write two sentences: the problem the user had, then what changed. Skip internal work unless the user feels it.
- Record a short clip of each headline feature. Ten to twenty seconds of the real UI does more than a paragraph. Record once with a screen recorder and you can reuse the same capture as the changelog visual, a step-by-step help article, and a social clip.
- Polish the stills. If you use screenshots, a consistent frame and background makes the changelog look deliberate. Our free screenshot beautifier handles that in the browser.
- Group the small stuff. Add "Improvements" and "Fixes" lists, each item tagged by area. This is where you thank the customers who reported bugs.
- Link to the docs instead of explaining everything. Keep the entry short and send readers to the updated guide for details. If the guide doesn't exist yet, that's your next task.
- Give every entry a URL and a feed. Permanent URLs make entries shareable; RSS lets people follow without remembering to check.
- Redistribute. Post the headline clip to social, send it to customers who asked for the feature, and add the newest entry to your onboarding emails.
Common mistakes this pattern avoids
- Version-number dumps. A list of ticket titles isn't a changelog. Linear's entries explain the problem before the feature.
- Marketing-only posts. Skipping fixes makes a changelog look like an ad. Linear keeps the fixes, and that makes the headline features more believable.
- Big-bang announcements. Saving everything for a quarterly launch means long silences. A steady cadence keeps you visible between launches.
- Release notes nobody can see. If the changelog only lives in an in-app modal, prospects, candidates, and investors never find it. Make it public and linkable.