A dashboard is not a data display. It is an answer to a question someone asks repeatedly. If you cannot name the question and the person, the dashboard is decoration.

The district needs three, not thirty: one for "is anything broken right now," one for "what is trending toward a problem," and one for "what does the director need to know."

One question per dashboard

Dashboard Question Audience Refresh
Health Is anything broken now? On-call, help desk 1 min
Capacity What will break in 90 days? Network engineer 1 hour
Service Are users able to work? Director 5 min

Mixing them produces a wall of panels where the on-call engineer scrolls past a storage forecast to find a red uplink.

The four golden signals

For any service, four numbers cover most of it:

Signal Network translation
Latency DNS time, TCP connect, TLS, TTFB
Traffic Requests per second, bytes per second
Errors Failed connections, 5xx, DHCP NAKs
Saturation Uplink utilization p95, PoE budget, DHCP pool

Put them at the top of the health dashboard, one row, one service per column. Everything else is drill-down.

Layout that respects the reader

Row 1  Status: one tile per service, green/amber/red + reason
Row 2  The four signals for the busiest three services
Row 3  Trends: 24 h, 7 d, with the same hour last week
Row 4  Detail: top talkers, recent alerts, links to runbooks

The top row should be readable from across the room. The bottom row should be clickable into a capture or a log query.

Do not encode status in color alone

About 8% of men have some form of color vision deficiency. A red/green tile with no text or icon is unreadable to them. Add a word ("degraded"), a shape, or a number.

Health, capacity, and service are three questions, not three dashboards on one page.

Time ranges that match the question

  • Health: last 15 minutes, 1-minute resolution.
  • Capacity: 90 days, 1-hour resolution, with a trend line.
  • Service: last 24 hours, 5-minute resolution, compared to the same day last week.

A single global time picker forces every panel to compromise. Give each dashboard a default that fits its question, and let the reader change it.

Worked example: the director's question

The director asks: "Is the network okay, and what should I worry about?"

A useful panel set:

  1. Availability: percentage of synthetic checks passing, last 7 days.
  2. Incidents: count by severity, last 30 days, with the top cause.
  3. Risk: three items — certificate expiring, PoE budget over 80%, firmware behind.
  4. Trend: internet latency p95, last 90 days.

Four panels, one screen, and every number has an owner and an action. That is a director dashboard.

What breaks in production

  • Forty panels because every metric seemed interesting once.
  • Vanity metrics (total bytes ever transferred) that never change a decision.
  • No time range or a global one that suits nothing.
  • Color-only status that some readers cannot see.
  • Stale data presented as live, because nobody checked the poller.
  • No links, so the dashboard tells you something is wrong and nothing about what to do.

Checklist

  1. Each dashboard names its question and audience.
  2. The top row is status, readable at a glance.
  3. The four golden signals are present for the key services.
  4. Default time ranges match the question.
  5. Status is encoded with text or shape, not only color.
  6. Every panel links to a runbook, a log query, or a capture point.
  7. Panels with no decision attached are removed.

Next

Monitoring closes the loop between what happened and what to do. The next series is VPNs and Remote Access, where the same discipline applies to a tunnel.

  • Dashboards
  • Visualization
  • Operations
  • Metrics