Green-Board Dashboard Design

A recipe for dashboards that show deviation instead of data — and the prompts that make an AI build one.

The idea

Suppress the normal

Most dashboards answer “what are the numbers?” Nobody asks that. The operator asks “is anything wrong, and where?” — a yes/no question that a wall of line charts answers slowly and badly.

A green board answers it in under a second from across the room. Healthy systems render as quiet, uniform, wordless green. Anything that breaks the pattern is the signal. You are not designing a display of data; you are designing a background the eye can ignore, so that the foreground means something.

The test that matters. Stand three metres back and squint. If you can still tell whether the system is healthy, the design works. If you have to walk closer and read, it does not.

Ingredients

Three layers, in this order

Each layer answers exactly one question and then stops. The operator descends only when the layer above gives them a reason to.

Layer	Answers	Contains
1 · The board	Is anything wrong?	A uniform grid of solid status blocks, one per system boundary. No numbers, no sparklines, no motion.
2 · The context card	What kind of wrong?	Opens on click. Three or four golden signals as key–value pairs. Nothing else. The board stays visible behind it.
3 · The detail plane	Why?	Time series, logs, traces. Hidden by default; reachable only from layer 2.

The golden signals are latency, traffic, errors and saturation. Four is the budget for layer 2. A fifth tile is a request to think harder about which four.

Taste it

The three layers, working

Click any block to open layer 2. Break a service to watch the worst-case rule bubble a child failure up to its parent.

Layer 1 — the board

Watch what your eye does. With labels hidden the board is almost unreadable as data and instantly readable as status. That asymmetry is the whole point — and it is why a green board is a poor report and an excellent alarm.

Rules

Three that never bend

1 · Three states, never two. “Up or down” is a lie that hides every interesting failure. Model healthy, degraded and critical, and give degraded a real threshold rather than treating it as a softer kind of broken.

2 · Worst case wins, recursively. A parent block inherits the worst state of any descendant. Four healthy children and one critical child make a critical parent. Averaging, or showing a percentage healthy, masks exactly the failure you built the board to catch.

3 · Chromatic restraint. Healthy green is dark moss, not neon — low saturation, low contrast against the page, close to invisible. Amber and red are the only saturated colour on screen. Spend brightness only on the exception.

The failure mode to design against is a board so loud when healthy that nobody looks at it when it changes. Every pixel of decoration you add to the normal state is borrowed from the alarm.

Method

Build it in this order

Layout last. The order below keeps you from decorating something whose meaning is not settled.

Name the boundariesList the things an operator would be paged about — “Payment Gateway”, not “pod-7c”. One block per boundary. If the list runs past about forty, you are one layer too deep.
Write the thresholds before the UIFor each boundary, state in one sentence what makes it degraded and what makes it critical. A board is only as honest as these numbers, and they are the part an AI cannot invent for you.
Build the roll-upModel the tree, then write the recursive worst-case evaluation. Test it with one bad leaf and confirm the root turns red.
Render layer 1 and stopBlocks, colour, nothing else. Resist the sparkline. Look at it from across the room before you go further.
Add layer 2 as an overlayFour signals, one deep-dive link, board still visible behind. If it needs a scrollbar, it is layer 3.
Link layer 3, do not design itIt is your existing metrics tool. The value you added is that nobody opens it until the board says to.

Prompts

Getting this out of an AI

Ask for a chart and you get a chart. These ask for a system. Name the principle explicitly — the vocabulary does real work in the model's output.

Radical Suppression of Normalcy Progressive Disclosure Worst-Case Aggregation Golden Signals

1 · Build layer 1 — the board

Act as a UI engineer building SRE dashboards. Design a system health overview that follows the Green-Board philosophy and Radical Suppression of Normalcy. Build a grid of uniform, flat status blocks, one per service boundary. When every metric is within threshold, each block is solid low-saturation green with zero text, zero charts and zero motion — the healthy state must be visually quiet enough to ignore. A block flips to high-contrast amber or red the instant a sub-metric breaches its warning or critical threshold. Constraints: no line charts, no scatter plots, no sparklines, no percentages in this view. Optimise for one thing — an operator spotting an anomaly from across the room in under a second.

2 · Build layer 2 — progressive disclosure

Add the interaction model to the status grid, following Progressive Disclosure. Clicking a status block reveals an overlay context card showing exactly the four golden signals — latency, traffic, errors, saturation — as plain key–value pairs, with the breaching value visually marked. Nothing else goes on this card. The grid stays visible behind the card so systemic context is never lost. Put one prominent "View deep-dive" action at the bottom that navigates to granular time-series and logs. Dismissing the card returns to the board with no state lost.

3 · Build the state logic

Write tool-agnostic state logic for a hierarchical monitoring dashboard. A parent service contains child components; each child evaluates live numeric metrics against a healthy / degraded / critical threshold set. Implement Worst-Case Aggregation: a parent recursively inherits the worst state of any descendant, so a single critical child makes the whole ancestry critical. Never average states and never report a percentage healthy — both mask the failure. Give me the state machine and the recursive evaluation as plain structures, no framework. Include the evaluation order and what happens when a metric is missing or stale — treat absent data as its own state, not as healthy.

4 · Improve a dashboard you already have

Critique this dashboard against Green-Board principles. For each element, tell me which of the three layers it belongs to — at-a-glance status, context card, or deep-dive detail — and flag anything sitting in the wrong layer. Specifically identify: elements that display data when nothing is wrong and should be suppressed; any place a binary up/down state hides a degraded state; any aggregation that averages or counts rather than taking the worst case; and any use of saturated colour on a healthy element that would weaken a real alarm. Return a prioritised list of changes, highest signal-to-noise gain first. Do not add new metrics — the goal is to remove and restructure.

Doneness test

Before you ship it

From three metres back, healthy and unhealthy are distinguishable without reading.
A fully healthy board contains no numbers at all.
One failing leaf turns every ancestor red, all the way to the top.
Degraded has its own threshold, written down, distinct from critical.
Missing or stale data shows as its own state and never as green.
Layer 2 fits on screen with no scrollbar and holds four signals at most.
Nothing on the board animates, blinks or refreshes visibly while healthy.
An operator can get from spotting a red block to a log line in two clicks.