How I Built a Modern Dashboard for GoatCounter - Rate Lim...

I use GoatCounter for my personal site analytics. If you haven't heard of it — it's a privacy-first, open-source analytics tool that doesn't track personal data. No cookies, no consent banners, lightweight script. I love it.

But the built-in dashboard is... minimal. It shows you the data, and that's about it. No interactive charts. No world map. No visual drill-down into browser versions or regions. For a tool that collects genuinely useful data, the presentation felt like it was leaving a lot on the table.

So I built my own dashboard.

Live demo (no account needed): https://abhishekhsingh.github.io/goatcounter-dashboard — click "Try Demo" to see it with sample data.

GitHub: https://github.com/abhishekhsingh/goatcounter-dashboard

What I wanted to build

I had a few constraints in mind from the start:

Single HTML file. No npm, no webpack, no build step. You should be able to fork the repo, enable GitHub Pages, and have a working dashboard. Or just download index.html and open it locally.
No server. The dashboard talks directly to your GoatCounter instance via the official API. My browser, your GoatCounter — nothing in between.
No tracking. Ironic to add analytics to an analytics dashboard. Zero telemetry, zero phone-home.
Privacy-first. API key stored in your browser's localStorage only. Never sent anywhere except your own GoatCounter instance. With those constraints locked, I started building.

The stack

React 18 + Recharts, loaded from CDN via <script> tags. JSX compiled in-browser by Babel standalone. Plain CSS with custom properties for theming. No bundler, no transpiler pipeline — the browser does everything.

Five CDN dependencies total: React, ReactDOM, Recharts, Babel standalone, and prop-types (a silent peer dependency Recharts needs at runtime).

The entire dashboard is about 3,000 lines in a single index.html. I know that sounds like a lot for one file, but it's surprisingly maintainable when you treat it as a self-contained application with clear component boundaries.

What the dashboard looks like

Here's what you get when you connect to your GoatCounter instance (or try the demo mode):

The layout, top to bottom:

4 KPI cards with period-over-period trend arrows (▲ +12.5% vs previous period)
Traffic area chart — visitors over time with gradient fill
Top Pages with click-to-expand referrer drill-down per page
3 donut charts — Browsers, OS, Devices — each with click-to-drill into versions
Choropleth world map with 174 countries, colored by visitor count, with a country list below that drills into regions/states
Languages card
Campaigns card (only shows when UTM data exists) Dark mode is the default. There's a light theme toggle if you prefer that.

The interesting technical challenges

1. Rate limiting without a backend

GoatCounter's API has a token-bucket rate limit — about 4 requests per second. My dashboard needs 13 API calls on initial load to populate all the cards. A naive Promise.all would fire all 13 at once and get throttled immediately.

I built a strict-sequential request queue. Each request waits for the previous one to complete (not just start), with a 500ms gap between completions. On the wire, that's about 2 requests per second including CORS preflights.

But 13 sequential requests at 500ms each means a 6-7 second load time. That's too slow. So I added lazy loading — the dashboard doesn't fetch data for cards that aren't visible yet.

Four tiers, triggered by IntersectionObserver:

Tier 1 (immediate): KPI totals + traffic chart — 3 requests
Tier 2 (scroll to donut row): Browsers, OS, Devices
Tier 3 (scroll to countries): Locations
Tier 4 (scroll to bottom): Campaigns The initial visible load is just 3-4 requests. Below-the-fold cards load as you scroll to them. Combined with a 60-second localStorage response cache, repeat visits are nearly instant.

2. A world map from TopoJSON with no build step

I wanted a choropleth world map — countries colored by visitor count. The standard approach is d3-geo at runtime, but d3 is way too heavy to load from CDN for just a map.

Instead, I wrote a one-time Node.js script (scripts/build-world-map.js) that converts Natural Earth 110m TopoJSON into pre-projected SVG paths. The script handles antimeridian wrapping (Russia, Fiji, Alaska all cross the date line), applies a Natural Earth projection, and outputs a plain JS file with 174 country objects — each containing the ISO code, country name, and a pre-computed SVG path d attribute.

The generated file (assets/world-map.js) is loaded as a separate non-Babel script tag. This is deliberate — Babel standalone recompiles the entire <script type="text/babel"> block on every page load, so keeping the 27KB of map paths outside that block saves compilation time.

The map itself is plain SVG with CSS hover effects. Countries with visitor data get colored on a sqrt scale (so small-count countries aren't invisible next to large ones). Hover shows a tooltip. When you click a country in the list below the map, all its disjoint territories highlight together — mainland US, Alaska, and Hawaii all light up.

3. GoatCounter's timezone trap

This one was subtle. GoatCounter's hourly traffic data returns an array indexed by hour — index 0 is midnight, index 11 is 11 AM. But these hours are in your site's configured timezone, not UTC.

My chart was building ISO date strings with a "Z" suffix (UTC), then letting JavaScript's Date object parse them. Since my browser is in IST (UTC+5:30), every data point shifted by 5.5 hours. The traffic chart showed a spike at 2 AM that was actually a spike at 7:30 AM.

The fix: parse the hour integer directly and format it for display without ever creating a Date object. The data is already in the right timezone — just don't let JavaScript "help" you with timezone conversion.

4. Drill-down everywhere

The built-in GoatCounter dashboard lets you click on a browser or country to see detailed breakdowns. I wanted the same thing.

Now every card supports drill-down:

Click a browser → see version breakdown (Chrome 124, Chrome 123...)
Click an OS → see version breakdown (Windows 11, Windows 10...)
Click a device category → see pixel widths
Click a country → see regions/states (the map highlights the selected country too)
Click a page → see referrer sources
Click a campaign → see referrer URLs The donut chart slices pop out when selected — a subtle +6px radius expansion with an accent stroke. It's a small detail, but it makes the interaction feel responsive.

5. Demo mode that doesn't cheat

I wanted people to try the dashboard without needing a GoatCounter account. So I built a demo mode with a buildDemoData() generator function (~280 lines) that creates self-consistent fake data on demand.

The generated data includes:

Weekday/weekend traffic patterns (weekdays are higher)
Two viral spikes baked into the 30-day curve (a Hacker News hit on day 8, a Reddit hit on day 22)
40 countries lighting up the world map
15 realistic blog post paths about distributed systems and MCP
Referrer breakdowns (Google, HN, Reddit, Twitter, LinkedIn)
Campaign tracking (hackernews-apr, reddit-selfhosted, twitter-thread) Everything sums correctly — country visitor counts roughly equal total visitors, browser percentages add to 100%. The generator produces different scaled data per date range (7d, 30d, 90d) so switching ranges actually changes the view.

All drill-downs work in demo mode too — click Chrome and you see version data, click United States and you see states. No API calls, all from static lookup tables.

Self-hosting

Fork the repo → enable GitHub Pages → done. Literally that simple.

Or if you want to host it yourself: download index.html, open it in a browser. It works from the file system — no server needed.

The dashboard connects to your GoatCounter instance using your API key. I never see your data, because there's no intermediary. Your browser talks directly to your GoatCounter.

What I learned

Building a non-trivial single-page application inside one HTML file with no build step is surprisingly viable in 2026. React + Recharts via CDN, JSX in the browser, CSS custom properties for theming — it all just works. The trade-off is that Babel standalone prints a console warning every time (yes, I know it's not recommended for production), but the actual performance is fine for a dashboard that loads once and stays open.

The rate-limiting work was the most educational part. GoatCounter doesn't document its rate limit algorithm in detail, so I had to discover it empirically — firing bursts of requests and observing where it started returning 429s. The token-bucket model meant that even 350ms gaps between requests weren't enough during a 13-request burst. Only a strict sequential queue with completion-based timing kept it reliably under the limit.

Live demo: https://abhishekhsingh.github.io/goatcounter-dashboard — click "Try Demo"