A dashboard for an infrastructure nobody could see

The problem

What does "healthy" even mean?

Kaleido is a Blockchain-as-a-Service platform. Customers spin up nodes, build consortiums, and run production environments without having to operate the underlying chain themselves. The trade is convenience for visibility — and that trade was starting to show.

Operators didn't have a clear way to answer the most basic question about their own environment: is this thing healthy right now? Block height, transaction throughput, node resource pressure — the data existed, but it lived in places only the protocol engineers knew how to read.

The framing question for the project came directly from the team:

That's a deceptively hard question. "Healthy" isn't a single metric. It's a pattern across several signals, read against a baseline that varies by chain, traffic, and configuration. The dashboard couldn't just display data — it had to help operators recognize when something was off, even before they knew what to look for.

Research

Five goals from engineer interviews

Interviews with protocol and DevOps engineers surfaced five design principles — each a yardstick I checked the design against later.

Chain Health

Surfacing the network signal

An environment has two fundamentally different layers — the chain itself, and the nodes running it. Engineers diagnosed them differently, so the dashboard splits along that same line: Chain Health and Node Health, two distinct mental models, two distinct visual treatments.

Chain Health answers the network-level question: is this chain doing what it's supposed to do? The default time window is the last 24 hours — long enough to see overnight patterns, short enough to feel current.

Two panels carry most of the load:

• Blocks. Transaction count across the previous 20 blocks. A flat line of empty blocks tells one story. A sudden spike tells another. Either way, you see the rhythm of the chain at a glance.
• Transactions. Transaction count over time, with a public/private toggle. Splitting them respects how operators actually think about workload — public traffic and private traffic have different shapes, different concerns, and different remediation paths.

Block height anchors the top of the section as a single, prominent number. It's the simplest signal of "the chain is moving" and the first thing engineers told me they look at when something feels off.

Node Health

From environment-wide to a single node

Node Health is the troubleshooting surface. The default view shows all nodes in the environment together, so operators can spot which one is misbehaving without having to know its name first. Click into a node and the same metrics narrow to that single instance — same vocabulary, same chart shapes, just scoped down.

The four metrics earned their place because they're what engineers said they actually check, in roughly this order:

• CPU utilization. The first place stress shows up. A CPU pinned for hours rarely ends well.
• Memory utilization. Slower-moving than CPU, and a cleaner indicator of leaks or runaway processes.
• Peer count. How aware nodes are of each other. A node that drops peers is a node that's about to fall behind the chain.
• Disk utilization. Blockchain data and logs only ever grow. Disk is the slow-burn problem that takes down environments quietly if you're not watching it.

Progressive disclosure does the heavy lifting here. The all-nodes view is intentionally calm — sparklines, no axes, no labels you don't need. The single-node view brings in detail: full charts, axis values, time-range scrubbing. The same component, two density levels, switched by user intent.

Reflection

What I'd tell you if you asked

This was an early-career project at Kaleido and the one I learned the most from about designing for technical operators. A few things I'd carry forward: