How I Check My RSS Subscriber Count
I wanted a rough idea of how many people subscribe to this blog through RSS. My RSS subscriber count now comes from reports sent by feed services, with their latest numbers stored in Cloudflare D1.
The result is incomplete, but useful. It tells me about subscriptions reported by those services, rather than everyone reading the feed.
Dariusz Winkler’s article about RSS subscriber counts gave me the starting point. I adapted the approach to the Cloudflare Worker that serves my site.
A feed request can represent several subscribers
Counting requests to /atom.xml would give me the wrong number.
A service can fetch the feed on behalf of multiple subscribers. Repeated requests can also come from the same reader checking for updates. Neither case tells me how many people read an article.
Some feed services include a subscriber count in their User-Agent header. Dariusz’s article shows examples from services including Feedly, Feedbin, and Inoreader. My counter looks for those reports and keeps the latest count for each recognised service.
To check the collected total, I run:
SELECT * FROM rss_subscriber_summary;
That returns three fields:
| Field | Meaning |
|---|---|
reported_subscriptions | Sum of recent counts reported by services |
reporting_services | Number of services included in that sum |
latest_report | Time of the most recent included report |
The word “reported” matters. This is information supplied by the requesting service, with the limits that come with that.
Keep one current count per service
The counter stores three values: the service name, its reported subscription count, and when the report arrived.
A new report replaces the previous count for that service. Repeated polling does not keep adding subscribers. A lower count replaces a higher one too.
The implementation also prevents an older observation from overwriting a newer one. That matters because database writes can finish in a different order from the requests that started them.
Only reports received within the last seven days contribute to the total. Seven days is a freshness rule I chose for this implementation. It prevents a service’s old count from staying in the total indefinitely.
If there are no recent reports, the query returns NULL. That means there is no recent data to count. It does not establish that nobody subscribes.
Check the RSS subscriber count in Cloudflare
I keep the count private. There is no public statistics page or counter attached to the blog.
In the Cloudflare dashboard, I open Storage & databases → D1 SQLite Database, select my RSS database, and open Console.
The summary query gives me the total. For the individual services, I run:
SELECT * FROM rss_subscriber_breakdown;
The breakdown shows each service’s latest count and report time. It also flags reports older than seven days as stale.
I prefer checking both views. A total is easier to interpret when I can see which services contributed to it.
These queries use views created for my counter. They are not built-in Cloudflare RSS statistics. The Cloudflare D1 query guide explains how to run SQL against a database.
The Worker observes the request and serves the feed
My website is generated with Hugo. Cloudflare serves the generated files, with the Worker configured to run first for /atom.xml.
The Worker retrieves the normal feed response through the static assets binding. For a successful feed request from a recognised reporting service, it updates D1 using a prepared statement.
The feed response passes through unchanged. If storing a report fails, the reader still receives the feed.
My counter stores aggregate reports only. It does not save IP addresses, complete User-Agent strings, email addresses, or individual reader identifiers. Those choices keep the database focused on the question I wanted answered.
What the count leaves out
A reader that sends no subscriber count contributes nothing to this estimate. The counter also ignores requests from readers it does not recognise, including NetNewsWire.
The number cannot tell me whether someone opened an article. A subscription is not a reading session, and one person can subscribe through several services.
There is another limitation: these reports are unauthenticated request headers. The parser rejects malformed values and unreasonably large counts, but that does not prove the remaining numbers are accurate.
I’m comfortable with that for a small, private estimate. I wanted some indication that people follow the blog, without adding tracking to the articles themselves. The service breakdown gives me that context, provided I remember what it cannot count.
Filed under Web Development and Tools on