Case study 12 / 17Data Viz
Privacy-first production observability for an on-premises platform
An admin-only console on the production site: 22 thresholded health KPIs, server-side session tracking and private usage analytics.
Stack
- TypeScript
- React
- Next.js
- MongoDB
- InfluxDB
- SVG
- Headless Chrome
01 · How it works
- TodaytoChanged in this work
- Data flow
What it does
An admin-only page in the monitoring platform's web client, on the production site, that shows how the system runs and how people use it. Health tracks 22 thresholded KPIs across services, data paths, events and restarts; Usage follows screens, drop-off and the time from an alarm to a decision.
Read more
Privacy was a design constraint: the page answers 404 to anyone but administrators and shows names only to the super administrator.
6 connections· select a part to trace it
- Web client to API auth check: data polls every 1–4 s
- API auth check to In-memory session list: records every requestchanged
- In-memory session list to Health and usage page: sessions seen in 2.5 min
- Web client to Usage allowlist: batched usage events
- Usage allowlist to Usage event store: keeps listed fields only
- Usage event store to Health and usage page: reads 1 h to 180 d
02Results
- R01Higher is better
History requests answered on a 24 h or 7 d view (of 11)
Before 3, after 11, 3.7× higher. Higher is better.BeforeAfter - R02Lower is better
Usage panels with overlapping or clipped labels (of 16)
Before 9, after 0, eliminated. Lower is better.BeforeAfter - R03Lower is better
Main-thread time with the page idle, per 30 s
Before 5.5 s, after 0.19 s, 29× lower. Lower is better.BeforeAfter
What it achieved
- Session tracking: a browser heartbeat one error could silence → derived server-side from every request the API already authenticates
- Long-range history: 3 of 11 requests answered → 11 of 11
Read more
- Usage panels: 9 of 16 with clipped labels → 0 of 16, guarded by a headless layout check
- Idle cost: 5.5 s → 0.19 s of main-thread time per 30 s
- A new session visible to administrators: after 60 s → within 1–4 s
The challenge
An observability layer must cost less and be more reliable than the system it observes. The first build was neither: idle, it spent a sixth of its time on the main thread repainting status lights, the map and every cell.
Long-range views fired eleven history requests into a rate limit that admitted three, with no retry.
Read more
In production the session count read zero with a tab open, because a single 404 had silenced the browser heartbeat for an hour. Restarts left no record, the time-series store never expired data, and more than half the usage panels had clipped or overlapping labels.
What I learned
Measure what a monitoring page costs before adding to it: idle animation, not data, was the main expense. Privacy shaped the architecture as much as performance did. The usage SDK stays under 5 KB and only queues events, so recording never re-renders the page.
Read more
I rejected a self-hosted analytics stack that required four services the server does not run, and hosted analytics that would move the data off-site. Clipped labels got a structural fix: one truncating component and a harness that fails on any overlap across 54 layouts.
Stack
- TypeScript
- React
- Next.js
- MongoDB
- InfluxDB
- SVG
- Headless Chrome
Skills
- Observability design
- Privacy by design
- Performance budgets
- Data visualization
- Automated visual testing
