dashboard-designerlisted

A dashboard is read in two modes: a calm weekly glance, and a 3am incident with an angry pager. Most dashboards are built for neither — they're a wall of every metric the system can emit, ranked by nothing, where the panel that matters is the same size as the one that never moves. This skill designs the opposite: a dashboard structured by a proven method (RED for request services, USE for resources) so the top row answers "is the service healthy?" in one glance, and the rows below answer "then where's the problem?" only when you need them. ## When to use this skill - A service is running in production with no dashboard, or only a default auto-generated one nobody trusts. - An existing dashboard is a 40-panel metric dump — technically complete, useless in an incident, because nothing is ranked. - Incident-readiness or on-call onboarding: you need a board a new engineer can read cold at 3am. - You're defining or visualizing SLOs and need error-budget burn to live next to the signals that drive it. - A postmortem found that the dashboard existed but the operator couldn't find the symptom on it fast enough. ## Instructions 1. **Classify the thing you're instrumenting, then pick the method.** Request-driven service (HTTP/gRPC/API) → **RED**: Rate (requests/sec), Errors (failed requests/sec and error %), Duration (latency distribution). Resource or queue (worker pool, broker, DB, cache, thread pool) → **USE**: Utilization (% busy), Saturation (queue depth / backlog / wait time),