name: dashboard-builder
description: Build monitoring dashboards that answer real operator questions for Grafana, SigNoz, and similar platforms. Use when turning metrics into a working dashboard instead of a vanity board.
origin: ECC direct-port adaptation
version: "1.0.0"

Dashboard Builder

Use this when the task is to build a dashboard people can operate from.

The goal is not "show every metric." The goal is to answer:

• is it healthy?
• where is the bottleneck?
• what changed?
• what action should someone take?

When to Use

• "Build a Kafka monitoring dashboard"
• "Create a Grafana dashboard for Elasticsearch"
• "Make a SigNoz dashboard for this service"
• "Turn this metrics list into a real operational dashboard"

Guardrails

• do not start from visual layout; start from operator questions
• do not include every available metric just because it exists
• do not mix health, throughput, and resource panels without structure
• do not ship panels without titles, units, and sane thresholds

Workflow

1. Define the operating questions

Organize around:

• health / availability
• latency / performance
• throughput / volume
• saturation / resources
• service-specific risk

2. Study the target platform schema

Inspect existing dashboards first:

• JSON structure
• query language
• variables
• threshold styling
• section layout

3. Build the minimum useful board

Recommended structure:

1. overview
2. performance
3. resources
4. service-specific section

4. Cut vanity panels

Every panel should answer a real question. If it does not, remove it.

Example Panel Sets

Elasticsearch

• cluster health
• shard allocation
• search latency
• indexing rate
• JVM heap / GC

Kafka

• broker count
• under-replicated partitions
• messages in / out
• consumer lag
• disk and network pressure

API gateway / ingress

• request rate
• p50 / p95 / p99 latency
• error rate
• upstream health
• active connections

Quality Checklist

• [ ] valid dashboard JSON
• [ ] clear section grouping
• [ ] titles and units are present
• [ ] thresholds/status colors are meaningful
• [ ] variables exist for common filters
• [ ] default time range and refresh are sensible
• [ ] no vanity panels with no operator value

Related Skills

• research-ops
• backend-patterns
• terminal-ops