DASHBOARDING

Last reviewed: 2026-09-17

Purpose: Dashboard design and data visualisation — dashboard types, panel and chart selection, layout and refresh strategy, alerting, and the tools used for operational and analytical dashboards.

Overview

A dashboard answers a specific question for a specific audience quickly. Two failure modes dominate: dashboards that show everything (and therefore answer nothing), and dashboards built for monitoring that are used for analysis. Decide up front which question is being answered, how often it is asked, and what action the viewer should take when a number looks wrong.

Dashboard Types

Type	Audience	Characteristics
Operational / monitoring	On-call engineers	Real-time, high refresh rate, thresholds and alerts, few panels, obvious pass/fail state
Technical / diagnostic	Engineers debugging	Fine-grained per-host or per-service breakdowns, links to logs and traces
Analytical / business	Analysts and managers	Historical trends, comparisons, filters over long time ranges, slower refresh
Executive	Leadership	KPIs and scorecards, month-over-month context, minimal detail, drill-through to detail dashboards

A monitoring dashboard that grows past roughly one screen stops being useful during an incident — split detail into a second, linked dashboard instead.

Design Principles

One question per dashboard. A title like "API availability" beats "Platform overview".
Show state, not just data. Colour-coded thresholds (green/amber/red) let a viewer assess a panel in under a second.
Left-to-right, most-important-first. Golden signals (traffic, errors, latency, saturation) go top-left.
Label units and time zones. Milliseconds versus seconds, and UTC versus local, cause more misreadings than any visual choice.
Annotate deployments and incidents on time series so a step change is explainable.
Default to a meaningful time range (last hour for operations, last 30 days for business) rather than "last 5 minutes".
Version dashboards as code — provision them from JSON/YAML in the repository so changes are reviewable and restorable.

Choosing a Visualisation

Intent	Chart
Trend over time	Time series (line/area); multiple series only when compared directly
Current value against a target	Stat/gauge with thresholds and a delta indicator
Distribution across categories	Bar chart, sorted by value
Share of a whole	Pie or donut — only with a handful of slices, otherwise use a bar
Distribution of many samples	Histogram or heatmap
Correlation between two metrics	Scatter plot
Raw detail with context	Table, with cell formatting and drill-through links
Flow or state change	State timeline / status history

Avoid dual axes on a single chart, 3D effects, and truncated Y-axes on bar charts — all three routinely mislead.

Layout, Refresh & Performance

Prefer a small number of wide panels over many narrow ones; a dashboard should be readable at 1280 px wide.
Group related panels into collapsible rows (overview row expanded, detail rows collapsed).
Use template variables (instance, job, environment) so one dashboard serves every environment instead of one dashboard per environment.
Choose a refresh interval matched to the data's granularity; refreshing a 15-second scrape every second wastes resources and produces noisy charts.
Push expensive aggregation to the query layer: record rules or continuous aggregates instead of rate() over a 30-day range on every load.
Test dashboards against the largest time range users commonly pick — that is where slow queries surface.

Alerting from Dashboards

Threshold lines make a dashboard readable; alerts make it actionable. Rules of thumb:

Alert on symptoms users feel (error rate, latency, saturation) rather than on every underlying cause metric.
Require a sustained breach (for: 5m) to avoid paging on a single spike.
Keep alert severity meaningful: one page-worthy tier, everything else a ticket or a channel notification.
Include a link to the relevant dashboard and runbook in the alert payload.
Review alert noise monthly — alerts that are routinely ignored train people to ignore real ones.

# Prometheus-style alert rule referenced by a dashboard panel
groups:
  - name: api-availability
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.05
        for: 5m
        labels: { severity: page }
        annotations:
          summary: "API error rate above 5% for 5 minutes"
          dashboard: "https://grafana.example.com/d/api-availability"

Tooling

Tool	Best for	Notes
Grafana	Operational dashboards over time-series and log data	Native Prometheus/Loki/Tempo/SQL data sources, provisioning as code, unified alerting
Kibana	Log and search-heavy visualisation	Strong on Elasticsearch aggregations
Streamlit	Internal Python dashboards, quick analytics apps	Fast to build, less control over layout and refresh
Plotly Dash	Interactive analytical web apps	Callback model, good for drill-down and custom interaction
Apache Superset	SQL-first BI, self-service exploration	Rich chart library over warehouse SQL
Power BI / Tableau	Business reporting with governed semantic layers	Licensed, strong for scheduled distribution

For streaming metrics, the serving layer matters as much as the chart: dashboards query a metrics store (Prometheus) or a real-time OLAP engine (Apache Pinot) with SQL, and the dashboard's refresh interval can never be faster than data actually lands in that store.

Operational Checklist

[ ] Dashboard title states the question it answers
[ ] Units, time zone and data source are visible
[ ] Thresholds or comparison baselines are set on key panels
[ ] Loading time under a few seconds at the widest supported range
[ ] Defined as code, reviewed in a pull request, stored in version control
[ ] Linked from the relevant runbook or alert, and reachable without a VPN surprise
[ ] Owner named, and panels that nobody reads removed

Topics Covered

Dashboard categories: operational, technical, analytical and executive
Design principles for readability and fast incident triage
Selecting the right chart type for a given question
Layout, template variables and refresh performance
Alerting from dashboards versus alerting in the monitoring backend
Tool selection across Grafana, Kibana, Streamlit, Dash, Superset and BI platforms