SaaS changelogs: writing updates when there’s no version number

On a versioned product, a release is an event. There’s a number, a date, an artifact someone can download, and a moment when “before” becomes “after.” Continuous deployment deletes the event. A SaaS product ships fifteen times on a quiet Tuesday, the interface changes under people mid-session, and there is no v2.3 to point at — ever. What’s easy to miss is that the question a changelog answers (“what changed, and when?”) doesn’t disappear with the version number. It gets asked more, because now nobody — not users, not support, not your own sales team — has any other way to name a change. For a versioned product, the changelog describes the release. For a SaaS product, the changelog is the release: the only place a deploy becomes a nameable, dateable, linkable fact. This guide is about writing that kind of changelog — the dated stream — and the handful of rules that are different when there’s no number on the tin.

When there’s no version, the date is the version

The format that won for SaaS is the dated stream: entries in reverse-chronological order, each with an absolute date, a human title, and a permalink. No version headings, no grouping by release — because there are no releases to group by. If you’ve read our versioning guide, this is the answer to its deciding question when nobody builds against your interfaces: version numbers are a compatibility promise, and a hosted app whose users can’t choose what version they run has no compatibility promise to make. Numbering it anyway is theater (more on that in the anti-patterns).

Two mechanical rules make the dated stream work. First, absolute dates, always — “March 12, 2026”, never “last week”, because entries are read months later from search results and support links. Second, one entry per change worth naming, not per deploy. The deploy is your unit of shipping; it is not the reader’s unit of caring. A week with forty deploys might honestly produce two entries, and that ratio is a sign of discipline, not laziness.

The entry threshold: deploys aren’t news

Versioned products get a free editorial filter: whatever made it into the release notes was, by definition, in the release. Continuous deployment removes the filter, so you need an explicit one. The test that holds up: would a regular user notice this change, or need to know about it? An entry is earned by new capability, by changed behavior someone will see, by a fix for a symptom users actually hit, and by anything that requires action or adjustment. It is not earned by refactors, dependency bumps, test coverage, or infrastructure work — with one honest exception: when invisible work has a visible outcome, write the outcome (“Search results now load about twice as fast”), not the work (“Migrated search to a new cluster”).

The rest of the shipping stream still deserves a record — it just isn’t this one. An internal changelog is the right home for per-deploy detail: support wants to know about the risky migration even if users never should. Two streams, two thresholds, one habit.

Feature flags break “when did this ship?” — pick the honest date

The hardest question in SaaS changelog writing is one versioned products never face: when a feature rolls out gradually — behind a flag, to 5% then 50% then everyone — when did it ship? For you, it shipped at merge, weeks ago. For most users, it appeared today. Date the entry at merge and readers will hunt for a feature they don’t have yet; announce at 5% rollout and support inherits a week of “I don’t see this button” tickets from the other 95%.

The rule: announce when generally available, and date the entry at the moment most users can see the change. If you must announce mid-rollout — a big launch with a marketing date, say — put the rollout state in the entry itself: “Rolling out over the next week; you’ll see the new editor when it reaches your workspace.” That one line converts a support ticket into patience. The timing discipline is the same canonical-URL-and-fan-out playbook as any feature announcement; what’s different in SaaS is only that you control the clock, so there’s no excuse for the entry and the availability to disagree.

Your users never agreed to this update

Here’s the trade nobody states out loud: in exchange for never having to run an upgrade, SaaS users give up the right to decline one. Every change you ship is an update they didn’t choose, arriving mid-workflow, with no downgrade path. That’s why surprise is more expensive for SaaS than for any versioned product — and why the changelog owes readers two courtesies that downloadable software can skip.

First, “what looks different” lines. When the UI changes, say what moved: “The share button now lives in the top bar.” People who’ve built muscle memory experience silent rearrangement as breakage, even when nothing broke.

Second, advance notice for workflow changes. In a hosted product, “breaking change” doesn’t mean a failed compile — it means someone’s Tuesday routine stopped working. Removals, redesigns of core flows, and changed defaults deserve the same announce-ahead treatment as an API removal: a dated heads-up entry before, the change entry on the day, and never, ever a silent removal. The feature you delete without a word is the one users were quietly depending on.

One boundary worth drawing precisely: all of this applies to the app surface. If your SaaS exposes an API, that API is an interface people build against, and it still needs real versioning — dated API versions in the Stripe style work well — and its own changelog discipline. “No version numbers” is a statement about the product, never about the contract.

Permalinks are your version numbers now

When a versioned product’s support team writes “fixed in 4.2.1,” that string is a coordinate: it tells the user what to check and when their problem ended. Your support team has no such string — unless the changelog provides it. A dated entry with a stable URL is the SaaS coordinate system: “This changed in the March 12 update [link]” works in a support macro, a sales follow-up, a status reply, a forum answer. This only works if entries have permalinks and titles that name the change (“Fixed CSV exports dropping the header row”), not the effort (“Various export improvements”). If your changelog can’t be cited, your product history lives in screenshots and tribal memory — which is to say, nowhere.

A minimal entry that does everything this guide asks:

A faster, rearranged editor toolbar        March 12, 2026  [improved]

The formatting controls moved from the right sidebar into the top
bar, and open about twice as fast. If you reach for the sidebar out
of habit: everything that lived there is now under the A-with-lines
icon, in the same order.

Rolling out over this week — you’ll see it when it reaches your
workspace.

Ship continuously, publish rhythmically

Continuous deployment doesn’t obligate continuous announcement. Three publishing rhythms work, and volume should pick between them: entry-at-ship for products with a few notable changes a month; a weekly digest when changes are constant (the Linear pattern — the reliable heartbeat becomes the message itself); a monthly roundup for slow-and-steady products. Whichever you pick, two rules from the cadence guide matter double here. Skip empty periods silently — a digest with nothing in it teaches people to stop reading. And don’t let the stream go quiet for months: for a hosted product, prospects read the changelog as a liveness check before they trust you with their data. A versioned product with no release for a year is stable; a SaaS changelog silent for a year is a going-out-of-business sign, fairly or not.

Anti-patterns

  • The deploy log as changelog. Forty entries titled “Deploy #4123” is a build artifact in public clothing. Nobody’s question is answered by it.
  • Invented version numbers. Calling this quarter’s batch “v2.5” of a web app users can’t hold, pin, or return to. The number promises a compatibility boundary that doesn’t exist; the first “can I stay on 2.4?” support ticket exposes it.
  • Dating at merge. The entry says March 3 because that’s when the code landed; users got the feature March 17. Every date in the changelog is now slightly a lie, and “when did this ship?” has no honest answer.
  • The weekly filler entry. “Small improvements and bug fixes” every Friday, forever. It exists to make the stream look alive and achieves the opposite — readers learn the words mean nothing.
  • Announcing at 5% rollout. The changelog says the feature exists; 19 of 20 readers can’t find it. Announce at general availability or say “rolling out” in so many words.
  • The silent removal. Shipping a deletion with no entry because “hardly anyone used it.” In a product where users can’t decline updates, the unannounced removal is the single fastest way to teach them your changelog is incomplete where it matters most.

Running a SaaS changelog with Wakelog

The dated stream is Wakelog’s native shape — dated entries, permalinks, tags, no version numbers required. The continuous-deployment loop maps on directly: post from the deploy pipeline with one curl when a change crosses the entry threshold; for flag-gated features, write the entry as a draft at merge and flip it live — or schedule it with publish_at — when the rollout hits everyone, so the date is the honest one. Permalinks give support the “fixed in” coordinate, tag filters keep fixes and features separately skimmable, and the embeddable widget puts “what’s new” inside the product, where SaaS users actually live. The honest caveat: no tool can decide what clears your entry threshold — the filter between deploys and news is the one part that stays a writing job.

Start your dated stream — free   Next: how often to publish →

Related guides

Last updated 2026-07-29 · All guides