What goes in an Amazon Redshift monitoring dashboard in Metabase?

An Amazon Redshift monitoring dashboard tracks query throughput and duration percentiles, WLM queue wait, queries that spill to disk, planner alerts, and the tables whose skew or sort state is dragging everything down. Metabase connects to Redshift natively, so every card is plain SQL over the cluster's own SYS_, STL_, SVL_, and SVV_ views.

What does a Redshift monitoring dashboard look like?

Here’s the layout this guide builds. Cluster-level health sits at the top; the middle section covers how queries behave — volume, percentiles, queue wait, and the duration mix; the bottom section is the diagnosis half, where disk spill, planner alerts, table skew, and storage growth name the specific thing to fix.

Which cards belong on a Redshift monitoring dashboard?

Eight cards, updated from the classic list: percentiles instead of average duration, and the three Redshift-specific failure modes — spill, skew, and queueing — given cards of their own.

• Queries by day and compute type — main cluster, concurrency scaling, serverless (stacked bar)
• Query duration, p50 and p95 by day (line)
• WLM queue wait vs. execution time by queue (line)
• Queries by duration bucket — under 1s through over 5 min (row)
• Disk-based queries per day, from spilled steps (bar)
• Planner alerts by type — missing statistics, nested loop, large broadcast (row)
• Cluster disk usage against capacity (line)
• Tables by skew and unsorted rows, with size (table)

What data does the dashboard need?

• SYS_QUERY_HISTORY — one row per query: status, elapsed_time, queue_time, execution_time, compute_type, error_message, and query text.
• STL_WLM_QUERY and STV_WLM_QUERY_STATE — service class, slot count, queue and execution time, plus what is queued right now.
• SVL_QUERY_SUMMARY (is_diskbased) and SVL_QUERY_METRICS_SUMMARY for spill, CPU time, blocks read, and rows scanned per query.
• STL_ALERT_EVENT_LOG for planner alerts, and SVV_TABLE_INFO for skew_rows, unsorted, stats_off, and table size.
• STV_PARTITIONS for disk usage, and SYS_SERVERLESS_USAGE if you run Redshift Serverless and want charged RPU-seconds on the same page.
• A nightly snapshot table, because the system views roll off in days — the trend cards need weeks.

How do you build it?

1. Connect Redshift to Metabase with a dedicated read-only user, granted SYSLOG ACCESS UNRESTRICTED so it sees every user’s queries rather than just its own.
2. Schedule a nightly job that appends yesterday’s rows from SYS_QUERY_HISTORY, the WLM views, and SVV_TABLE_INFO into snapshot tables — this is the only way to keep history past the retention window.
3. Model the snapshot once: microseconds to seconds, duration buckets, and a disk-based flag joined in from SVL_QUERY_SUMMARY, so every card agrees on the definitions.
4. Build the percentile and queue-wait cards first — they tell you whether the cluster is execution-bound or admission-bound — then the spill, alert, and skew cards that name the fix.
5. Add filters for database, user or query group, and date range, and alert the platform channel when disk usage or the disk-based query count crosses its threshold.

Example card SQL

SELECT
DATE_TRUNC('day', start_time)                          AS day,
COUNT(*)                                               AS queries,
SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END)     AS failed,
ROUND(PERCENTILE_CONT(0.50) WITHIN GROUP (
  ORDER BY elapsed_time) / 1000000.0, 1)               AS p50_s,
ROUND(PERCENTILE_CONT(0.95) WITHIN GROUP (
  ORDER BY elapsed_time) / 1000000.0, 1)               AS p95_s,
ROUND(AVG(queue_time) / 1000000.0, 2)                  AS avg_queue_s,
SUM(CASE WHEN compute_type = 'concurrency scaling'
         THEN 1 ELSE 0 END)                            AS on_burst_clusters
FROM sys_query_history
WHERE start_time >= DATEADD(day, -14, GETDATE())
AND query_type = 'SELECT'
GROUP BY 1
ORDER BY 1;

Related

Metrics

Integrations

Dashboards

FAQ