What goes in an IT monitoring dashboard in Metabase?

An IT monitoring dashboard is the operations team's live view of the whole estate — servers, network devices, endpoints, and SaaS services — showing what's up, what's alerting, and where latency or disk capacity is drifting. It goes wide where a server monitoring dashboard goes deep, and Metabase builds it from monitoring rollups landed in your warehouse.

What does an IT monitoring dashboard look like?

Here’s the layout this guide builds. Estate status leads — devices down and active alerts are the two numbers on-call actually acts on — followed by alert and availability trends, with network health and disk capacity at the bottom, where drift shows up days before it becomes an outage.

Which cards belong on an IT monitoring dashboard?

The eight below answer the on-call question in order: is anything down, is anything about to be, and is the network the reason?

• Device status by class — up, degraded, down across servers, network, endpoints, and SaaS (table)
• Active alerts by source — which tool is firing (donut)
• Alerts per day by severity, two weeks (stacked bar)
• Uptime by device class, daily, against a 99.9% goal (line)
• Network latency p95 by site (line)
• Packet loss by WAN link (row)
• Volumes closest to full, with free space and growth (table)
• SaaS service status — current state and 30-day uptime per service (table)

What data does the dashboard need?

• devices — inventory with device_id, device_class, site, and an active flag, usually from the CMDB or the monitoring tool’s own registry.
• device_checks — one row per device per check with timestamp and up/degraded/down status.
• alerts — alert ID, source tool, severity, fired and resolved timestamps.
• network_metrics — per-link latency, packet loss, and utilization samples from SNMP or your NMS.
• disk_usage — per-volume capacity, used bytes, and snapshot date for headroom and growth.

How do you build it?

1. Land monitoring data in the warehouse on a schedule: pull the Prometheus or Datadog APIs every few minutes, or mirror collector output straight to a checks table.
2. Build a “latest status” model with DISTINCT ON (device_id) so status cards read a few thousand rows, not the whole history.
3. Create hourly rollups for uptime, latency, and alert volume — the trend cards query these, keeping refresh fast.
4. Add the capacity table from disk_usage, computing daily growth per volume and sorting by percent used.
5. Add filters for site, device class, and date range, and set auto-refresh to one minute if the dashboard runs on a wall display.

Example card SQL

WITH latest AS (
SELECT DISTINCT ON (device_id)
  device_id,
  status,
  checked_at
FROM device_checks
WHERE checked_at >= now() - interval '15 minutes'
ORDER BY device_id, checked_at DESC
)
SELECT
d.device_class,                      -- server / network / endpoint / saas
COUNT(*)                                        AS devices,
COUNT(*) FILTER (WHERE l.status = 'up')         AS up,
COUNT(*) FILTER (WHERE l.status = 'degraded')   AS degraded,
COUNT(*) FILTER (WHERE l.status = 'down')       AS down,
COUNT(*) FILTER (WHERE l.device_id IS NULL)     AS not_reporting,
ROUND(100.0 * COUNT(*) FILTER (WHERE l.status = 'up')
  / NULLIF(COUNT(*), 0), 2)                     AS pct_up
FROM devices d
LEFT JOIN latest l ON l.device_id = d.device_id
WHERE d.is_active
GROUP BY d.device_class
ORDER BY down DESC, degraded DESC;

Related

Metrics

Integrations

Dashboards

FAQ