Dashboards overview

What dashboards are

Dashboards turn the queries you prototype in the Data Explorer into a curated, always-on view your team returns to. A drag-and-drop designer lets you assemble 20+ widget types — charts, stats, tables, heatmaps, RUM and alert panels — pulling from metrics, logs, traces, RUM, and alert data on one canvas. Use them for service health boards, on-call NOC screens, and capacity-planning views.

Where the Data Explorer answers a one-off question, a dashboard answers the recurring one — and does it the same way every time, for everyone. Build the query once, pin it, and share it. Open Dashboards from the main sidebar to start.

When to use a dashboard

Use a dashboard when…	Use another view when…
A team needs the same set of charts repeatedly	You're exploring an ad-hoc question — use the Data Explorer
You want an at-a-glance health board for on-call	You need to be actively notified — configure Alerts
You want to standardize a view across environments	You want to read individual events — use Logs / Tracing

The three modes

Mode	Route	What you do
List	/dashboards	Browse, search, create, clone, share, delete.
View	/dashboards/:id	Read-only viewing, change variables and time range, share.
Edit (designer)	/dashboards/:id/edit	Add/arrange widgets, configure queries, set variables.

Best practices

• Do compile metrics queries with the Builder first, then hand-tune — it produces the shape the platform expects (see Writing widget queries).
• Do group correlated widgets together — CPU, memory and disk on the same row so a saturation story reads at a glance.
• Do place key KPIs in Stat widgets at the top.
• Do start from a template and customize, rather than an empty canvas.
• Do name dashboards descriptively — "Production API — Latency and Errors", not "Dashboard 2".
• Don't put a real-time board on a 30-day range; use ~1h for live monitoring and 7d for trends.
• Don't overload one dashboard — many focused boards beat a single wall of 40 widgets.