A dashboard is a visual collection of panels, such as time-series charts, heatmaps, tables and single values, each driven by a query over telemetry data. In observability, dashboards summarize the health of services and infrastructure at a glance and serve as the starting point for drilling down into traces, logs and profiles.
What a dashboard is
A dashboard arranges several panels on one screen so that people can see the current and recent state of a system without writing queries. Each panel is a saved query, for example the request rate of a service, its p99 latency or the memory usage of its pods, rendered as a chart, heatmap, table or single number. Template variables such as environment, cluster or service let one dashboard serve many targets.
Dashboards are the most visible part of monitoring, but they answer only the questions someone thought of in advance. That is the core difference between monitoring and observability: a good dashboard tells you that something is wrong and roughly where; the ability to slice data freely and jump into traces and logs tells you why.
Types of dashboards
| Type | Audience | Typical content |
|---|---|---|
| Service overview | Owning team, on-call | Rate, errors, duration, saturation, SLO status, recent deployments |
| Infrastructure | Platform team | Nodes, pods, CPU, memory, disk, network, autoscaling events |
| Dependency / database | Service owners, DBAs | Query latency, connections, locks, replication lag |
| Business / executive | Product, leadership | Orders, sign-ups, revenue-relevant conversion, SLO compliance |
| Incident / investigation | Responders | Ad-hoc panels created during an incident, often discarded afterwards |
What belongs on a service dashboard
Proven frameworks give structure. The RED method (rate, errors, duration) fits request-driven services; the USE method (utilization, saturation, errors) fits resources such as CPUs, disks or queues; and the four golden signals combine both views. A useful layout puts user-facing signals at the top, then dependencies, then resources:
- SLO status and error budget remaining.
- Request rate, error rate and latency percentiles (p50, p95, p99) or a latency heatmap.
- Calls to downstream dependencies with their latency and errors.
- Saturation: CPU throttling, memory, connection pools, queue depth.
- Deployment and configuration-change markers on every time-series chart.
Design principles
- Start from a question. "Is checkout healthy right now?" leads to a better dashboard than "show all checkout metrics".
- Prefer percentiles and heatmaps over averages. An average latency can look fine while the slowest 1% of users wait seconds.
- Keep units and axes consistent. Show rates per second, durations in the same unit, and start error charts at zero.
- Make panels clickable. Link from a latency spike to example traces, ideally via exemplars, and from errors to the matching logs.
- Treat dashboards as code. Store definitions in version control (for example JSON, Jsonnet or Terraform), review changes and generate standard dashboards per service from templates.
Choosing the right visualization
- Time series for rates, error ratios and resource usage over time; the default for almost everything that changes.
- Heatmaps for latency distributions. They reveal bimodal behavior, for example cache hits versus misses, that a single percentile line hides.
- Single values with thresholds for SLO compliance or remaining error budget, where one number answers the question.
- Tables for top-N lists such as the slowest endpoints or the noisiest pods, sorted by impact.
- Service maps for dependencies, so responders can see which upstream or downstream service is affected.
Avoid pie charts for operational data and stacked charts for values that are not meant to be summed, such as percentiles.
Example: a RED panel query
An illustrative PromQL query for a p99 latency panel by route, based on an OpenTelemetry HTTP server histogram exported to Prometheus:
histogram_quantile(0.99,
sum by (le, http_route) (
rate(http_server_request_duration_seconds_bucket{service_name="checkout"}[5m])
)
)Note that quantiles are computed after summing buckets across instances. Averaging per-instance p99 values is a common and misleading shortcut.
Common mistakes
Dashboard sprawl is the most common problem: hundreds of dashboards, many copied, half of them broken, none clearly owned. During an incident nobody knows which one to trust. Other mistakes are panels with dozens of overlapping lines, queries that group by high-cardinality labels such as user IDs and make dashboards slow, and using dashboards as the primary alerting mechanism, which only works while someone is looking.
Regularly delete dashboards that have not been viewed in months, assign an owner to every remaining one and keep a small set of curated, linked entry points per team.
How Obseria helps
Obseria creates service dashboards automatically from OpenTelemetry data and the topology in Obseria TopoGraph, and every panel can be edited with OQL, PromQL or SQL. Dashboards are included in all plans without per-seat limits and can be managed as code through the API and CLI. From any chart you can drill into traces, logs and profiles; the service catalog links each dashboard to its owning team.
