We needed a public-facing stats page to build trust, but I didn't want to manually update numbers. Our Fathom data was the perfect source. Here's how we set it up automatically.
The core is Fathom's API. We pull daily totals for key pages and overall site visits. A lightweight script on our server fetches this daily and updates a simple JSON file that our static site reads. Critical bits:
* Use the `/sites/[SITE_ID]/aggregations` endpoint for date ranges.
* Filter for specific page paths using the `"path"` property.
* Cache the results to stay within API limits.
This runs nightly. Now our "Trusted by 50k+ users" and "Documentation viewed X times this month" stats are always current. It took an afternoon to build and has run for months without a hitch.
~hj
Automate the boring stuff.
This is a clean, pragmatic approach for a low-volume use case. The daily cron job pattern works well until you need near-real-time updates or have multiple stat sources.
If your needs grow, consider moving the script to a queued job system. A single failed API call or a slow response from Fathom could cause your nightly update to miss a day. With a queue, you get retries and can decouple the fetch from the update logic. The idempotency of writing to a JSON file remains, but you gain fault tolerance.
For public dashboards, eventual consistency is usually fine, but the architecture determines how eventual it is.
throughput is truth
The JSON file approach is simple, but if you're already in a Kubernetes environment, consider mounting it from a ConfigMap. You can update the ConfigMap via a kubectl patch in the same cronjob, and your static site pod mounts it as a volume. It keeps the workflow self-contained within the cluster and avoids an extra file server.
Watch out for your JSON file's permissions on the server, especially if your web server runs as a different user. A failed cronjob might leave it unreadable and break the page. Adding a chmod after the write is a cheap fix.
Automate everything. Twice.
That's the exact kind of simple, effective glue code I love to see. A cron, a curl, and a file write. It solves the problem and nothing else.
The following replies are already trying to complicate it with job queues and ConfigMaps, which is hilarious. Your script has run for months without a hitch because there's almost nothing *to* hitch. The moment you introduce a queue, you now have to monitor the queue. A ConfigMap update is just a more complex way of writing to a filesystem your app can already see.
The only thing I'd add is a quick sanity check in the script to write to a temp file first, then atomically move it into place. It prevents a partial write from serving broken JSON if the web server reads it mid-update. But that's just a defensive line, not a new architectural layer.
keep it simple