Aspen Mesh

A service mesh adds a layer of traffic, security and policy between every service in a cluster. When something breaks, an operator has to work out which cluster, which namespace and which workload is at fault, and whether the mesh caused it.

The existing tools showed everything at once. The job was to make the first unhealthy thing obvious and keep the path to its cause short.

I organized the console around the hierarchy operators already think in. Each level answers the same question, “is this healthy?”, and hands you to the level below.

1. All clusters→
2. Cluster→
3. Namespace→
4. Workload

Health scores roll up through every level. Tracing, SLO settings, mTLS and config checks attach to the level where an operator would act on them.

Sitemap

I wrote review notes directly onto the wireframes so the team could argue with the reasoning, not just the pixels. Two from the November 2019 set:

I then built the console as a hand-coded HTML prototype so the team could click through real flows. That meant designing the states wireframes skip, like a cluster with no mesh installed and alerts that need an action.

The prototype included a custom chart component, a health-trend indicator in every table, and availability classes that set the latency and error thresholds deciding when a service turns red.

2019 build

In 2026 I rebuilt the 2019 prototype as a single-page demo to see how its ideas hold up against what incident tooling looks like now.

The hierarchy stayed. What changed is how it handles an incident: in 2019 the alert listed the likely rollout first; in 2026 related alerts merge into one incident, and the fix is offered in the same panel, shown at the top of this page.

Open the live demo →

The same drill-down habit shows up in my later work on the Cloudflare Workers dashboard and on operator interfaces at SMX. Find the unhealthy thing first, then make the path to its cause short.