💡 Local Dashboards + The (new) Judoscale API

I like dashboards

As long as I’ve been building software, I’ve enjoyed having data about that software on some sort of physical screen or device around me. On one hand, I’ve always felt it’s important to see your metrics with your own eyes — you might detect anomalies or patterns that don’t trigger your alerts outright, but which still may be important bugs. On the other, it feels cool to have charts on TVs 😎.

Just for a few quick examples, these are the sorts of datas I want to keep ahead of me on the day-to-day. Scout’s stack-aware, color-coded bar charts:

Application performance monitoring dashboard showing response times and throughput over approximately 24 hours, from October 14–15. Response times remain consistently low, with occasional brief spikes in database and controller processing. Key metrics include a mean response time of 3.9 ms, 95th percentile response time of 0.2 ms, throughput of 2.1 requests per minute, zero errors, memory usage of 361.3 MB, and a perfect Apdex score of 1.000. — A low volume app performing well!

Betterstack’s system-level metrics (plus making any chart you want from logs data! ✨):

Heroku application monitoring dashboard displaying performance metrics from approximately 5:40 AM to 6:35 AM. Availability is 99.8%, with request throughput averaging around 200 requests per minute and peaking near 500. The 99th-percentile request time frequently reaches 16 minutes and 40 seconds, while the 95th percentile shows occasional spikes of several minutes. Application service time exhibits similar fluctuations. Router connection times remain consistently below 1 millisecond. HTTP responses are predominantly successful (2xx), with occasional redirects and client errors. Web dyno memory remains stable near 6.7 GiB, while web dyno load fluctuates between approximately 50% and 250%, briefly peaking above 400%. Background worker loads remain comparatively low.

And Judoscale’s scale, queue time, and utilization data:

Judoscale autoscaling dashboard showing application performance from approximately 6:20 AM to 6:39 AM. The application is running 13 dynos, handling 2,313 requests per second with 50.4% utilization and a queue time of 3.0 ms. Throughput remains relatively stable, while queue time briefly spikes to approximately 55 ms around 6:31 AM before returning to normal. Utilization rises temporarily during the same period but otherwise remains between approximately 30% and 50%. Dyno count remains steady throughout the displayed interval.

All of these datapoints can help you answer specific questions about your app’s current health in a glance. That’s useful!

That said, if you’ve ever tried to setup and run your own device-based dashboards, you’ve probably also experienced the pain it can be: setup a browser on some sort of device/TV, log in to your service(s), pull up the chart(s) you want, then configure a browser extension to automatically switch between tabs and refresh the pages on a given interval. Oh, and that system will break/die/crash once every month or two, so make sure you keep the remote / mouse / keyboard nearby!

Running a physical (TV/iPad/etc) metrics dashboard has always required a certain level of futzing.

Also, I’ve used plenty of service providers in the past that have great, beautiful dashboards and charts, but that weren’t made with long-running in mind! They were made to be pulled up when needed, looked over for a few minutes, then closed. Expecting them to stay alive (polling data, getting updates, refreshing their rendering, etc) over the span of weeks reveals even the smallest of Javascript memory leaks (as your Chrome instance balloons to tens of GB of memory…). The browser-extension style of “switch to the next tab and refresh it” works (I’ve used it for years) but I think it’s time for something entirely new.

The new way

There are so many factors and perspectives to talk about with today’s AI tooling for developers, but I’ve been mulling over a notion of ‘personal software’ — building the things you need from scratch, or forking existing projects, and building them deliberately around your own domain model. Example: need a CRM? Just make one — one that fully understands exactly how your pipeline and communication styles work — instead of grabbing Hubspot off-the-shelf (etc.) and trying to configure it to your workflow.

Eventually I got to wondering what the ‘personal software’ equivalent of dashboards and metrics charts would be. A DIY solution to rendering data… in a way that I prefer, a style that matches my app itself, and a system that I can control and change whenever, and however, I want to. 💡 Can I use AI to build my own chart dashboards?

The answer is yes. And because I didn’t want to spin up third party cloud hosting just for my dashboards, I realized a neat architecture for this: a simple, local HTML file that loads the data, paints it into a chart, and handles the data refreshes with simple, local Javascript. As long as my metric providers have open API’s that I can pull the data from, I can just render it myself!

So… a few prompts later, and pointing Safari at file:///Users/jsull/Developer/repos/local_web_dashboards/_example_dash.html yields this beautiful cross-service view (this one in particular is for larger physical screens, hence the small-appearing charts):

Application performance dashboard combining Judoscale and Better Stack metrics for October 14–15. The application averages 118.4 ms response time, 238.1 requests per minute, and 0.1 errors per minute. Infrastructure charts show a shared Puma and Sidekiq dyno operating at approximately 40–50% of its memory limit, with dyno load generally near 1.0. Request queue times remain mostly below 50 ms, with occasional spikes exceeding 200 ms. Web traffic fluctuates between approximately 150 and 450 requests per minute. HTTP 5xx error rates remain near zero, with brief spikes below 0.25%. Mean response times are generally around 100–150 ms, while 95th-percentile response times remain relatively stable except for isolated spikes approaching 2 seconds.

And here we can see system metrics, application metrics, and queue time metrics all rendering into the same page. No tab switches needed! 🎉

Alternatively, I have a four-panel set of screens for an iPad-size view, complete with auto ‘page’ rotation (every five minutes) through the four pages noted on the top right. Page 1 for high level system basics:

Application traffic monitoring dashboard showing Heroku router metrics over 24 hours, from October 14–15. Average response time is 118 ms, throughput is 238.7 requests per minute, and errors average 0.1 per minute. Request volume fluctuates between approximately 150 and 450 requests per minute, increasing toward the end of the period. HTTP 5xx error rates remain near zero, with occasional spikes below 0.25%. Mean response times generally range from 90–150 ms, with an isolated spike approaching 370 ms. The 95th-percentile response time remains relatively stable around 200–300 ms, except for a brief spike approaching 1.8 seconds.

Another page for revealing response times, throughput, and queue time all in the same scope (monitoring capacity, essentially):

And a few other application-level metrics pages (think, “X forms submitted over time” or “X tasks outstanding”) after that.

✅ Tip

I’m not getting super specific or detailed about how these are built here because the beauty of the idea is that you can create your own extremely simply with today’s AI tooling; the ‘how it actually works’ doesn’t matter so much these days. The point is that we’re no longer beholden to web UI’s and dashboard frameworks from other providers. Just pull the data from them and build your own dashboard(s)! Exactly how you want.

The Judoscale API

Long-time Judoscale customers/readers might’ve started wondering as they read through to this point, “Wait, Judoscale has a data API I can just consume??” We do now! It was serendipitous timing that Carlos was finishing up the full new Judoscale API the same week I had this idea about local, data-driven, custom dashboards! Complete with a downloadable OpenAPI spec document you can feed into your preferred LLM/Agent, it’s easy to hop into the Judoscale web UI to generate a read-only API token.

Screenshot of the Judoscale Team API documentation at api.judoscale.com, displayed in a dark-themed browser window. The documentation introduces API version 1.0.0, using OpenAPI 3.2.0, with programmatic access to teams, applications, processes, autoscaling settings, metrics, and scaling history. The left sidebar lists API endpoints for team management, memberships, API tokens, apps, processes, metrics, restart events, scale events, schedules, and models. The main content explains bearer-token authentication, including member and admin roles and read-only or read-write permissions. A right sidebar displays the API server URL, authentication settings, and available client libraries.

Of course, local dashboards and data rendering are great for the read-only tokens, but the new API supports all readable and writeable actions available in the web UI. So feel free to build a neat integration into your own control-plane applications and leverage the power of Judoscale wherever, and however, you’d like!

We’re also excited to say that an official Judoscale CLI and MCP are both on their way, for those interested. 😎

❗ Important

One last note on local dashboards: building dashboards in this way requires your providers to support CORS preflight clearance requests (since you’re running Javascript on localhost or similar). To date, we’ve found that DigitalOcean, Scout, and Betterstack all support this style of fetching. Oh, and Judoscale, of course 😉.