> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Amazon Redshift on Vortex IQ > Monitor Amazon Redshift health, cost and reliability signals, and catch incidents and runaway spend early. Monitor Amazon Redshift health, cost and reliability signals, and catch incidents and runaway spend early. No changes are made without the configured approval policy. Read-only operations do not modify the connected system; schedules, access scopes, API usage and data handling remain governed by Vortex IQ controls. [Connect or manage this source](https://app.vortexiq.ai/workbench/settings/sources) ยท [How connecting works](/integrations/connector-catalogue) | **29** | **12** | **Build your own** | **Ready to build yours** | **6** | | ------------------- | ---------------- | ------------------ | ------------------------ | -------------- | | performance signals | automated checks | automated fixes | workflows | API operations | ## Monitor performance 29 performance signals. Signals with an alert band can raise Nerve Centre alerts; every signal supports a merchant-configured watcher. | Signal | Outcome | Alert behaviour | What it tracks | | ------------------------------------------------------ | ----------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Connection Saturation %** | Run operations | Alert band 70 / 90 | DatabaseConnections / max\_connections. Redshift caps at 500 (default) - saturation = app login timeouts. | | **Cross-Region Snapshot Lag (s)** | Run operations | Alert band 1 / 10 | Lag of cross-region automated snapshot copy (disaster-recovery replica freshness). | | **Disk Space Used %** | Run operations | Alert band 70 / 90 | CloudWatch PercentageDiskSpaceUsed. Full disks fail writes, vacuums and sorts - the #1 Redshift outage cause. | | **Disk Space Used >90%** | Run operations | Alert band 0 / 1 | Alerts for Disk Space Used >90%. | | **Last Snapshot Age (hours)** | Run operations | Alert band 24 / 72 | Age of the most recent automated/manual snapshot (DescribeClusterSnapshots). Redshift auto-snapshots on a schedule. | | **Queries Completed / sec** | Run operations | Watch only | CloudWatch QueriesCompletedPerSecond - live throughput. | | **Queries Spilling to Disk (24h)** | Customer experience | Merchant rule | Redshift-distinctive - queries spilling to disk (SVL\_QUERY\_SUMMARY is\_diskbased) indicate undersized memory / bad joins. | | **Query Error Rate %** | Protect revenue | Alert band 0.1 / 1 | Aborted / errored queries over total (SYS\_QUERY\_HISTORY.status = 'failed'). | | **Query Error Rate Spike (>1% in 5m)** | Control risk and change | Alert band 0.1 / 1 | Alerts for Query Error Rate Spike (>1% in 5m). | | **Query Latency p95 (ms)** | Customer experience | Alert band 50 / 200 | Warehouse p95 measured over analytics queries - threshold reflects warehouse, not OLTP, use. | | **Redshift Connection Saturation vs Traffic Burst** | Protect revenue | Alert band 70 / 90 | Redshift Connection Saturation vs Traffic Burst, broken down by row. | | **Redshift Health Score** | Control risk and change | Merchant rule | Composite of disk usage, WLM queueing, query error rate and connection saturation. | | **Redshift Query Spike vs Ecom Order Rate** | Protect revenue | Merchant rule | Query load should track business volume. Divergence = runaway job / dashboard storm burning warehouse spend. | | **Redshift Table Row Count vs Ecom Catalog Size** | Protect revenue | Merchant rule | Redshift-distinctive XC - ecom data lands in Redshift via ETL; row drift = pipeline / sync failure. | | **Result Cache Hit Rate %** | Customer experience | Alert band 95 / 80 | Share of queries in the last hour served from the Redshift result cache (SYS\_QUERY\_HISTORY.result\_cache\_hit) - same query set already read for Slow-Query Rate. | | **Slow Analytics Queries During Checkout Window (5m)** | Protect revenue | Merchant rule | Slow Analytics Queries During Checkout Window (5m), broken down by row. | | **Slow-Query Rate %** | Customer experience | Alert band 1 / 5 | Share of queries with elapsed\_time over the 5s slow threshold (SYS\_QUERY\_HISTORY). | | **Tables Needing VACUUM** | Run operations | Merchant rule | Redshift-distinctive - SVV\_TABLE\_INFO.unsorted. High unsorted rows = full scans = slow queries + wasted disk. | | **WLM Queue Length** | Run operations | Merchant rule | Redshift-distinctive - CloudWatch WLMQueueLength. Sustained queueing = under-provisioned WLM / add concurrency scaling. | | **WLM Queueing Sustained (>5 queued)** | Run operations | Alert band 0 / 1 | Alerts for WLM Queueing Sustained (>5 queued). | | **Active Connections** | Run operations | Watch only | CloudWatch DatabaseConnections. | | **Avg WLM Queue Wait (ms)** | Run operations | Merchant rule | Avg WLM wait before execution from STV\_WLM\_QUERY\_STATE / query queue\_time. | | **CPU Utilisation %** | Run operations | Merchant rule | CloudWatch CPUUtilization (leader + compute average). | | **Largest Table (GB)** | Run operations | Watch only | From SVV\_TABLE\_INFO.size - top tables drive disk pressure. | | **Max Table Distribution Skew** | Run operations | Merchant rule | Redshift-distinctive - SVV\_TABLE\_INFO.skew\_rows. High skew = one slice does all the work (bad DISTKEY). | | **Queries Blocked on Locks** | Control risk and change | Merchant rule | From STV\_LOCKS / SVV\_TRANSACTIONS - blocked transactions waiting on locks. | | **Query Latency p50 (ms)** | Customer experience | Watch only | From SYS\_QUERY\_HISTORY.elapsed\_time percentiles. | | **Tables with Stale Statistics** | Run operations | Merchant rule | SVV\_TABLE\_INFO.stats\_off - stale ANALYZE leads the planner to bad join orders. | | **Top 10 Slowest Queries** | Customer experience | Watch only | Top 10 Slowest Queries, broken down by row. | ## Audit risks and opportunities A fix status appears only where the action, inputs, approval, verification and recovery controls are mapped. Candidate remediations are never executable. | Check | Severity | Outcome | Why it matters | Fix status | | ----------------------------------------------------- | -------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | **Connection pool saturation above 90%** | critical | Customer experience | At 90% of the connection pool in use, the database is close to refusing new connections outright. Once it does, every part of the application that needs a fresh database connection, includin | Report only | | **Disk usage above 90%** | critical | Run operations | A database that runs out of disk stops accepting writes entirely, which for most stores means orders, inventory updates and customer records stop being saved, not just that the database gets | Report only | | **Query error rate above 1% in last 5 minutes** | critical | Run operations | More than 1 in 100 queries is failing right now. Depending on what those queries do, this can mean orders not saving, pages failing to load product or customer data, or background jobs silen | Report only | | **Last successful backup older than 72 hours** | high | Run operations | If something goes wrong with this database right now, the most recent point it can be restored to is over 3 days old. Every order, customer record and inventory change since that backup woul | Report only | | **Replication lag above 10 seconds** | high | Run operations | Anything reading from the replica, reports, dashboards, or read traffic split off the primary for capacity, is now up to 10+ seconds stale. If the primary fails while lag is this high, the r | Report only | | **Slow-query rate above 5% of total** | high | Customer experience | More than 1 in 20 queries is landing in the slow bucket. That is frequent enough to be a pattern, not noise, and it means a meaningful share of every page load or job that touches this datab | Report only | | **WLM Queue Length >5 Sustained 5m** | high | Run operations | Queues sustained above 5 in workload management mean the cluster is undersized or a workload is misplaced; everything behind it runs late. | Report only | | **p95 query latency above 200ms sustained 15m** | high | Customer experience | One in twenty queries against this database is taking over 200ms, sustained for at least 15 minutes, not a brief spike. Any storefront page, checkout step or order sync that depends on this | Report only | | **Buffer / cache hit rate below 80%** | medium | Run operations | More than 1 in 5 reads is missing the cache and going to disk instead, which is markedly slower. This shows up as everything the database does feeling incrementally heavier, rather than as o | Report only | | **Queries Spilling to Disk >10 in 24h** | medium | Customer experience | Queries spilling to disk run orders of magnitude slower than in memory; the offending queries are identifiable and usually tunable. | Report only | | **Tables With >10% Unsorted Rows (VACUUM Candidate)** | medium | Customer experience | Tables over 10 percent unsorted degrade every scan that touches them; VACUUM restores the performance already paid for. | Report only | | **Tables With Stale Statistics (ANALYZE Candidate)** | low | Customer experience | Stale statistics mislead the query planner into bad plans; ANALYZE is the cheapest performance fix the cluster has. | Report only | ### Build your own automated fixes 12 checks report findings on Amazon Redshift today. Turn any finding into an automated fix with a Vortex IQ workflow: **13,885 read and write operations across 229 connectors** are available as building blocks, with approval, verification and rollback on every change. ## Automate approved work Vortex IQ is integrated with **0 read** and **6 write** operations across cloudwatch:getmetricdatas, redshift:describeclusters, redshift:describeclustersnapshots, redshiftdata:describestatements, redshiftdata:executestatements, redshiftdata:getstatementresults on Amazon Redshift. Combine them with anything from the **13,885 operations across 229 connectors** to automate the work in your own words. Changes follow the merchant's configured approval policy: the target, proposed change, affected records, risk, reversibility and verification plan are shown before execution. Read-only operations do not modify the connected system. [Create a workflow](https://app.vortexiq.ai/workbench/flows/create?connector=redshift) | Resource | Read operations | Write operations | | --------------------------------- | --------------- | ---------------- | | cloudwatch:getmetricdatas | 0 | 1 | | redshift:describeclusters | 0 | 1 | | redshift:describeclustersnapshots | 0 | 1 | | redshiftdata:describestatements | 0 | 1 | | redshiftdata:executestatements | 0 | 1 | | redshiftdata:getstatementresults | 0 | 1 | Signed-in users see the full catalogue in the workflow builder, filtered to the sources they have connected. ### Ready to build your first Amazon Redshift workflow Pick a trigger, add the operations above as steps, and every step that changes data pauses for your approval. Monitoring and audits are live now and can start any workflow you build. *** *Generated from the connector capability graph. Counts reflect the servable registry after alias normalisation and de-duplication, and refresh automatically when the registry changes.*