Do users actually read changelogs?
Teams debating whether a changelog is worth maintaining usually argue from anecdote, because hard public data on changelog readership is thin. Here's what actually exists — a couple of surveys, some academic work, and engagement benchmarks from adjacent channels — and what it does and doesn't support.
The direct evidence: some people genuinely read them
The most-cited direct number comes from a survey by technical writer James Scott, in which 83.6% of respondents said they read release notes or app update notes. Treat the figure with care — a survey circulated by a documentation writer will oversample people who care about documentation — but it undercuts the confident claim that "nobody reads release notes."
Academic work points the same direction for technical audiences. A study of 32,425 release notes across 1,000 GitHub projects, paired with a survey of 314 practitioners, found release notes genuinely used by both the people producing them and the people consuming them — alongside a recurring mismatch between what producers write and what readers want from them. And an empirical study of release notes in popular Google Play apps exists precisely because app release notes are a real communication channel worth analyzing.
So the defensible reading of the direct evidence: readership is real, skews toward technical and engaged users, and depends heavily on whether the notes are written to be read.
The proxy evidence: the channel determines the rate
Nobody publishes "changelog page visit rates," but the delivery channels around changelogs have benchmarks:
- Announcement-style emails perform surprisingly well as a category: MailerLite's analysis of 3.6 million campaigns puts the median email open rate at 43.46%, with software and web apps at 39.31%.
- Push notifications do far worse: average click-through rates around 2.25% across industries, with reported open rates that vary wildly by source, from roughly 4% to 20%.
These aren't changelog-specific numbers, and we haven't found a credible public benchmark that is. But the spread supports a practical conclusion: the same update announcement can reach a large minority of users or almost none of them, depending on the channel — which is why every serious guide treats distribution as the main problem. A changelog page alone, with no delivery mechanism, sits at the bottom of that range; guidance on pairing the page with in-app and channel delivery is in changelog best practices for SaaS.
What raises the odds of being read
Two levers show up consistently in practitioner guidance, stated here as qualitative claims because the underlying numbers are vendor-reported: entries written as user impact rather than commit messages, and updates targeted at the users the change affects rather than blasted to everyone — the central argument of Userpilot's product-updates guide, among others. The GitHub-projects study above lands on the same first point from the academic side: the producer-reader mismatch is a writing problem, not a readership problem. The craft half of the answer is covered in how to write release notes people actually read.
The wrong question
Notice what "do users read changelogs" quietly assumes: that the changelog's job is broad readership. For most SaaS teams the highest-value readers are a handful of specific people — the customers who asked for the things in this release. For them, the relevant question isn't open rates; it's whether anything in your process guarantees they find out at all. A changelog is a broadcast, and broadcasts reach whoever happens to be looking.
Targeting those readers directly is the case we build Modem around, so weigh our interest here: it tracks who asked for what across Slack, Discord, and support, and when the resolving PR merges, it drafts release notes and individual follow-ups matched to the requesters. The targeting rests on a context graph that keeps each person linked to their requests across channels, so the list of who to tell is a lookup rather than a reconstruction. If your users are anonymous — an open-source tool, a consumer app — there's no requester to target, and the broadcast changelog carries the whole load.
The verdict
Yes, a meaningful share of users read changelogs — the surveys say so, with the caveat that readers skew technical and self-selected. No, most users won't seek yours out, which is what the channel benchmarks imply. The practical position: keep the changelog because its readers are disproportionately your most engaged users and evaluating prospects, deliver it through a channel with real reach rather than relying on the page, and route the updates that matter most — shipped requests — directly to the people who asked, where readership stops being a statistics question.
