Dashboard
A saved screen of operational charts and queries, arranged so you can tell whether a service is healthy at a glance.
See it
What it is
An observability dashboard is a saved visual view that puts operational queries, charts, tables, and status panels in one place. A useful one answers a specific question, such as 'is checkout healthy?', with traffic, errors, latency, and saturation visible on the same clock. Grafana is the familiar example, but the artifact is the saved view, not the product that renders it.
Reach for a dashboard when several signals must be read together during a deploy, an incident, or a daily health check. Start with the golden signals, keep units and time windows consistent, and add links from summary panels into the logs or traces that explain the change.
Gotcha: a wall of charts can create the feeling of control without helping anyone decide. Panels with different time ranges tell false stories, averages hide tail latency, and template variables can leave someone staring at the wrong environment. Give every panel an owner and a question, then delete the ones nobody uses.
Ask AI for it
Build a Grafana dashboard for this service using Prometheus as the data source. Add RED panels for request rate, error rate, and p50, p95, and p99 duration, plus saturation panels for CPU, memory, queue depth, and in-flight work. Use one shared time range, explicit units, environment and service template variables, deployment annotations, and links from error and latency panels into matching Loki logs and Tempo traces. Return provisionable Grafana dashboard JSON and keep the overview to one screen.