Integration
Redshift Monitoring: Amazon Redshift Data Monitoring and Observability for Freshness, Volume, and Anomalies
Keep your Redshift clusters honest with monitoring for freshness, volume, schema, and anomalies on every table.
14-day trial, no credit card, read-only connection
Alerted #data-eng 0.8s ago.
Downstream impact · consumers at risk
In one paragraph
Redshift data monitoring continuously checks your Amazon Redshift tables for freshness, volume, schema, and anomaly issues, and maps lineage across your schemas. Dataobservability connects with read-only access, reads system tables and statistics rather than scanning data, and alerts your team when something breaks.
Side by side
Amazon Redshift monitoring and data quality options compared
Swipe to see all columns →
| Option | What it watches | Setup | Blind spot |
|---|---|---|---|
| CloudWatch metrics and alarms | Cluster and serverless health: CPU, disk, connections, queue depth, RPU consumption | Native, alarms per metric | Says nothing about whether the data in the tables is correct |
| SYS_QUERY_HISTORY and SYS_QUERY_DETAIL | Every query that ran, with duration, rows, and error state, including running queries | SQL against system views, plus somewhere to send results | Query level facts only. A COPY that loaded zero rows succeeded |
| Redshift Advisor and enhanced query monitoring | Performance bottlenecks, distribution and sort key advice, diagnostics | Built into the console | Performance tuning, not data correctness |
| AWS Glue Data Quality (DQDL) | Rules you author in DQDL against Redshift tables cataloged in the Glue Data Catalog, with labels for prioritization | Catalog the table, write rules, schedule the ruleset | Only the rules you wrote, on the tables you cataloged |
| Hand built SQL checks in Airflow or Step Functions | Whatever you encode | You build scheduling, storage, thresholds, dedup, and alerting | Engineering time, and every check competes for cluster resources |
| Data observability platform (Dataobservability) | Freshness, volume, schema, and distribution on every table, with learned baselines and column level lineage | Read only connection, monitors generate automatically | Published pricing from $99 a month |
Summarized in good faith from public documentation, August 2026. Verify current behavior and terms with the vendor.
Why it fits
Redshift teams who want modern observability on their existing warehouse.
Reads system catalogs
Monitoring leans on Redshift system tables, keeping cluster load minimal.
Full-pillar coverage
Freshness, volume, schema, and anomaly monitors across every schema.
Mapped impact
Lineage shows the downstream reports affected by any break.
Redshift monitoring versus Redshift data observability
Search for Redshift monitoring and almost everything you find is about the cluster: CloudWatch metrics, WLM queue depth, disk usage, concurrency scaling minutes, RPU consumption on Serverless, and the query tuning advice in Redshift Advisor. That work matters and you should be doing it, but it answers a different question than the one that wakes people up. Cluster monitoring tells you the warehouse is healthy. Data observability tells you the contents are correct. The two diverge constantly. A COPY command from S3 completes in four seconds with a green status and loads zero rows, because the prefix it pointed at was empty. CPU is fine, no query failed, and the fact table quietly stops growing. An upstream system starts sending a status field with a new value nobody mapped, so a CASE statement drops those rows into an else branch and a segment silently shrinks. A schema migration adds a column and an unqualified INSERT starts writing NULL into it. In every case the cluster metrics are perfect. The system views will show you queries ran successfully. The only way to catch these is to measure the data itself against what it normally looks like: did this table update on schedule, did it receive the volume it usually receives, did its schema change, did the values in its important columns shift shape.
Getting real signal out of Redshift system views
If you want to build Redshift monitoring yourself, the system views are the right foundation and it is worth knowing which ones. SYS_QUERY_HISTORY holds one row per user query with duration, status, and row counts, covering DDL, DML, COPY, UNLOAD, and Spectrum, and it includes running queries as well as finished ones. SYS_QUERY_DETAIL breaks a query down by step, which is what the enhanced query monitoring added in early 2025 leans on for diagnostics. SVV_TABLE_INFO gives you row estimates, size, and skew per table without scanning anything. STL and SVL views still exist but AWS has been steering new work toward the SYS views, and the SYS views are the ones that behave consistently across provisioned and Serverless. The pattern that works: use SVV_TABLE_INFO for volume and size trends because it is free, use SYS_QUERY_HISTORY filtered to COPY and INSERT statements per target table to derive a last loaded timestamp for freshness, and use the catalog views for schema snapshots you can diff. What you will then have to build yourself is the part that takes the time: somewhere durable to store the history, baselines that adapt per table rather than fixed thresholds, deduplication so one broken upstream does not fire two hundred alerts, routing to whoever owns the pipeline, and a lineage graph to answer who is affected. That last mile is usually six months of engineering, and it is why most teams that start building this end up buying it.
AWS Glue Data Quality on Redshift, and what it does not cover
AWS has a first party answer for data quality rules on Redshift: Glue Data Quality. You catalog the Redshift table in the Glue Data Catalog, then author rules in DQDL, a domain specific language for expressions like row count ranges, completeness thresholds, uniqueness, and column value sets. AWS added DQDL labels in January 2026, which let you attach business metadata to rules so you can organize and prioritize them at scale. It runs on Glue, results land where you can alert on them, and it keeps everything inside your AWS account, which is often the deciding factor for regulated teams. The limits are the same shape as every rules based approach. Coverage is exactly the rules you wrote on the tables you cataloged, so the table a new pipeline created last month has no rules on it and therefore reports no problems, which reads identically to being healthy. Thresholds are static unless you maintain them, so a row count range that was right in January is wrong by June and either fires constantly or never fires. And rules do not learn shape: a completeness rule of 95 percent passes at 96 percent whether the normal value is 96 or 99.9. If you have a small set of critical tables with well understood business rules, Glue Data Quality is a reasonable and cheap fit. If you want coverage across a warehouse where new tables appear regularly, you want monitors that generate themselves and baselines derived from each table's own history.
Monitoring Redshift Serverless without paying for it twice
Redshift Serverless changes the economics of monitoring in a way that catches teams out. On a provisioned cluster the compute is already paid for, so an extra count query every fifteen minutes is close to free. On Serverless you are billed for RPU seconds, so every monitoring query that scans a table is a line item, and a monitoring job that wakes the endpoint every few minutes can keep it from ever idling down. Teams discover this when the Serverless bill roughly doubles in the month they turned on data quality checks, and the usual reaction is to cut monitoring back to a handful of tables, which is the wrong trade. The fix is the same as on Snowflake and BigQuery: answer with metadata whatever metadata can answer. Freshness comes from the last load recorded in query history rather than a MAX(updated_at) scan. Volume comes from SVV_TABLE_INFO row estimates rather than a COUNT star. Schema comes from the catalog. Those three cover the large majority of real incidents and none of them reads a data block. Distribution monitoring genuinely has to sample values, so run it on a slower cadence and only on columns that matter. Dataobservability works this way by default across provisioned clusters and Serverless workgroups, which is what makes it practical to monitor every table rather than the twenty you can justify.
Frequently asked questions
What is Redshift data observability?
Redshift data observability means continuously monitoring your Amazon Redshift tables for freshness, volume, schema changes, and distribution anomalies, and mapping lineage across schemas and into downstream reports. It differs from cluster monitoring, which watches CPU, disk, queues, and query performance but cannot tell you whether the data those queries returned is correct.
How do I monitor Amazon Redshift?
Use three layers. CloudWatch for cluster or Serverless health metrics and alarms. The SYS views, particularly SYS_QUERY_HISTORY and SYS_QUERY_DETAIL, for query level history and diagnostics. Then a data quality layer, either AWS Glue Data Quality rules on cataloged tables or a data observability platform, for whether the data itself arrived on time, in the right volume, with the expected schema and shape.
What is SYS_QUERY_HISTORY in Redshift?
SYS_QUERY_HISTORY is a Redshift system view with one row per user query, carrying accumulated statistics such as duration, status, and rows affected. It covers DDL, DML, COPY, UNLOAD, and Spectrum queries, and includes both running and finished queries. It is the usual source for deriving a last loaded timestamp per table when you build freshness checks yourself.
Can AWS Glue Data Quality check Redshift tables?
Yes. You catalog the Redshift table in the AWS Glue Data Catalog and author rules in DQDL, the Data Quality Definition Language, covering things like row counts, completeness, uniqueness, and accepted value sets. AWS added DQDL labels in January 2026 for organizing rules by business context. Coverage is limited to the rules you write on the tables you catalog.
Does monitoring slow down my Redshift cluster?
It depends entirely on whether the tool scans tables or reads metadata. Repeated COUNT and MAX queries across thousands of tables compete for cluster resources and, on Redshift Serverless, bill RPU seconds and keep the endpoint from idling. Reading SVV_TABLE_INFO for row estimates and query history for load times answers freshness and volume without touching a data block, which is how Dataobservability runs by default.
What is the difference between Redshift monitoring and data quality monitoring?
Redshift monitoring watches the warehouse: CPU, disk, WLM queues, concurrency scaling, RPU usage, and query performance. Data quality monitoring watches the tables: whether they updated on schedule, received the expected number of rows, kept their schema, and held their normal value distributions. A COPY that loads zero rows is a perfect result to the first and a serious incident to the second.
Does Dataobservability work with Redshift Serverless?
Yes, on both provisioned clusters and Serverless workgroups. The connection is read only and the checks are metadata first, reading SVV_TABLE_INFO and query history rather than scanning tables, which matters more on Serverless because scans are billed as RPU seconds and frequent monitoring queries can keep a workgroup from ever scaling down to zero.
Live on day one
Connect your warehouse and watch monitors generate across every table. Transparent pricing, no credit card.