Amazon Redshift Monitoring: Data Quality, Freshness, and Anomalies

To monitor data quality in Amazon Redshift, you watch four things: freshness (did each table load on time), volume (did the expected number of rows arrive), schema (did a column change type or disappear), and distribution (did the values themselves drift). Redshift gives you the raw signals in its system tables, mostly STL, SVL, and SVV views, plus SYS monitoring views on Redshift Serverless. You can read freshness and volume from metadata cheaply, catch schema drift by diffing SVV_COLUMNS, and detect anomalies with SQL. What Redshift does not give you is a system that watches every table, learns each one's normal, tells you why a number moved, and pages the right person. This guide covers both halves.

Last updated July 2026.

How do I monitor data quality in Amazon Redshift?

Monitor Redshift data quality by checking freshness, volume, schema, and distribution on a schedule, reading the cheap signals from system tables before you ever scan a row. Freshness comes from load history, volume from row counts, schema from the catalog views, and distribution from sampled column statistics. Alert when any of them departs from the table's normal range. The trap teams fall into is scanning full tables on every check, which turns a trivial question into an expensive cluster workload; read metadata first and reserve row scans for the checks that genuinely need them.

The signals live in a few places. Load and query history is in STL_LOAD_COMMITS, STL_QUERY, and the newer SYS_LOAD_HISTORY and SYS_QUERY_HISTORY on Serverless. Table and column structure is in SVV_TABLE_INFO and SVV_COLUMNS. Row counts and table size sit in SVV_TABLE_INFO as well. Because these are catalog and log views, querying them barely touches your compute, which is exactly what you want for a check that runs every hour and usually confirms nothing is wrong.

Checking freshness and volume from Redshift system tables

Freshness is the highest-value check because a stale table is the most common cause of a wrong dashboard. For a table loaded by COPY, the last successful load time is in the load history:

SELECT MAX(curtime) AS last_load FROM stl_load_commits WHERE query IN (SELECT query FROM stl_query WHERE querytxt ILIKE '%your_table%');

On Redshift Serverless, prefer SYS_LOAD_HISTORY, which is cleaner and retained longer. Compare the last load time to the expected cadence: a table that loads hourly and last loaded four hours ago is a freshness incident, whether or not any row is wrong. Volume follows the same idea. Track the row count from SVV_TABLE_INFO over time and flag when today's count falls outside the range the table normally lands in for that day of the week. A Monday that loads 10 percent of a normal Monday's rows is a partial-load failure, and it will not trip a not_null assertion because the rows that did arrive are fine.

Both of these read metadata, not table data, so they cost almost nothing. That matters on Redshift, where full-table scans on a busy cluster compete with production queries for slots.

Detecting schema drift and anomalies

Schema drift is a snapshot diff. Store the output of SELECT column_name, data_type FROM svv_columns WHERE table_name = 'your_table' each day, then compare today's against yesterday's. A new column, a dropped column, or a type change (a numeric column that became a varchar because an upstream export changed) is a schema event worth an alert, because it silently breaks downstream joins and casts.

Distribution and value anomalies are the harder half, because they need history and a sense of normal. A rolling z-score gets you started: compute a trailing mean and standard deviation of a metric (daily revenue, null rate on a key column, count of a category) over a window, and flag any day more than three standard deviations out. It is crude, it assumes rough normality, and it has no idea that Mondays are quiet, so it will page you every Monday if you do not account for seasonality. That limitation is the whole reason learned baselines exist: they model the weekly and daily shape you would otherwise hand-code and get wrong. If you want the deeper version of this across every table, continuous anomaly detection learns each column's pattern instead of asking you to set thresholds.

What Redshift and CloudWatch cover, and what they do not

Amazon publishes real monitoring surface for Redshift, and it is worth using. CloudWatch tracks cluster and query metrics (CPU, disk, query duration, WLM queue depth), and Redshift's own console shows query performance and load errors. Those tell you the warehouse is healthy and queries are running. They are infrastructure monitoring, not data quality monitoring. CloudWatch will happily report a green cluster while a table quietly loaded half its rows, because from the cluster's point of view the COPY succeeded. The gap is the difference between "is Redshift up" and "is the data in Redshift correct," and only the second one shows up on the dashboard your stakeholders read.

There is also an upstream reality worth naming. Most Redshift data quality problems start before Redshift, in the pipelines and connectors that load data into it from your operational apps and APIs. A source system that changed a field, an integration that loads your apps and databases into the warehouse and silently dropped a batch, a reverse-ETL job that ran twice: the symptom lands in Redshift, but the cause is upstream. This is why lineage matters so much for triage, because without it you are staring at a wrong number in a Redshift table with no map of where it came from.

Where a warehouse-wide observability layer takes over

You can build all of the above yourself with scheduled SQL, a results table, and a Lambda that posts to Slack. Many teams do, and for a handful of critical tables it is a reasonable amount of work. The cost shows up when you scale it: 300 tables, each needing its own freshness cadence, its own volume baseline, its own schema snapshot, and its own maintenance every time the business changes. Hand-authored checks cover the tables somebody had time to author, which is never all of them, and the incident always seems to hit the one nobody got to.

A data observability platform inverts the work. It connects to Redshift read-only, discovers every table automatically, learns each one's normal freshness, volume, and distribution from history, and monitors all of them continuously without you writing per-table rules. It reads the cheap metadata signals (load history, row counts, catalog views) the same way you would by hand, so it stays light on the cluster, and it layers column-level lineage across the warehouse so an alert arrives with the downstream models and dashboards it affects. That last part is what turns an anomaly from a fact into an action. If you are standing up data quality monitoring on Redshift and you would rather not maintain a growing pile of SQL checks, that is exactly the job a monitoring layer does, and Dataobservability connects to Redshift (alongside Snowflake, BigQuery, and Databricks) in about 15 minutes with pricing published from 99 dollars a month. For the Redshift-specific setup, see the Redshift data observability page.

Frequently asked questions

How do I monitor data quality in Amazon Redshift?

Check freshness, volume, schema, and distribution on a schedule, reading cheap signals from system tables first. Get freshness from load history (STL_LOAD_COMMITS or SYS_LOAD_HISTORY), volume from row counts in SVV_TABLE_INFO, schema drift by diffing SVV_COLUMNS day over day, and distribution from sampled column statistics with a rolling baseline. Alert when any signal departs from the table's normal range, and reserve full-table scans for the checks that truly need row-level data.

Does CloudWatch monitor Redshift data quality?

No. CloudWatch monitors Redshift infrastructure (CPU, disk, query duration, queue depth) and tells you the cluster and queries are healthy. It does not know whether a table loaded the right rows or whether a column changed type. A COPY can succeed, keeping CloudWatch green, while the data it loaded is half-missing or wrong. Data quality monitoring is a separate layer that watches the contents of tables, not the health of the cluster.

What system tables show Redshift data freshness?

Use STL_LOAD_COMMITS for COPY load times on provisioned clusters and SYS_LOAD_HISTORY on Redshift Serverless, which is cleaner and retained longer. For query-based loads, STL_QUERY and SYS_QUERY_HISTORY record execution times. Compare the last successful load against the table's expected cadence: if an hourly table last loaded four hours ago, that is a freshness incident regardless of whether the rows already present are valid.

Is native Redshift monitoring enough, or do I need a data observability tool?

Native Redshift and CloudWatch monitoring are enough for infrastructure health and for a small number of critical tables you check by hand. They fall short when you need to watch every table, learn each one's normal without writing rules, catch anomalies nobody wrote a threshold for, and trace an issue through column-level lineage to the dashboards it affects. At that scale a data observability platform that connects read-only and monitors the whole warehouse continuously saves far more engineering time than it costs.