> ## 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 DynamoDB on Vortex IQ > Monitor Amazon DynamoDB health, cost and reliability signals, and catch incidents and runaway spend early. Monitor Amazon DynamoDB 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) | **30** | **7** | **Build your own** | **Ready to build yours** | **9** | | ------------------- | ---------------- | ------------------ | ------------------------ | -------------- | | performance signals | automated checks | automated fixes | workflows | API operations | ## Monitor performance 30 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 | | ------------------------------------------------------ | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Consumed Capacity (RCU+WCU, live)** | Run operations | Watch only | ConsumedReadCapacityUnits + ConsumedWriteCapacityUnits Sum over the last minute. | | **DynamoDB Health Score** | Control risk and change | Merchant rule | Composite of throttle rate, error rate, latency p95 and capacity utilisation. | | **GetItem Latency p95 (ms)** | Customer experience | Alert band 50 / 200 | SuccessfulRequestLatency p95 with Operation=GetItem. DynamoDB targets single-digit ms - p95 over baseline is a real regression. | | **Global Table Replication Lag (seconds)** | Control risk and change | Alert band 1 / 10 | CloudWatch ReplicationLatency for global tables, converted to seconds. Gated - only meaningful when global tables are configured. | | **Provisioned Capacity at >80% Utilisation** | Run operations | Alert band 0 / 1 | Alerts for Provisioned Capacity at >80% Utilisation. | | **Provisioned Read Utilisation %** | Protect revenue | Alert band 70 / 90 | ConsumedReadCapacityUnits / ProvisionedReadCapacityUnits (PROVISIONED tables). >80% sustained = throttle risk; check auto-scaling. | | **Provisioned Write Utilisation %** | Run operations | Alert band 70 / 90 | ConsumedWriteCapacityUnits / ProvisionedWriteCapacityUnits (PROVISIONED tables). | | **Query Latency p99 (ms)** | Customer experience | Alert band 100 / 500 | SuccessfulRequestLatency p99 with Operation=Query. | | **Read Throttle Events (24h)** | Run operations | Merchant rule | Sum of ReadThrottleEvents. Spike = under-provisioned reads or a hot partition. | | **Slow-Query Rate %** | Customer experience | Alert band 1 / 5 | CloudWatch Percentile Rank (Stat=PR(200:)) on SuccessfulRequestLatency - the % of samples above 200ms, computed server-side by CloudWatch from the underlying sample set ( | | **System Error (5xx) Spike** | Control risk and change | Merchant rule | Alerts for System Error (5xx) Spike. | | **System Errors (5xx, 5m)** | Control risk and change | Merchant rule | SystemErrors - DynamoDB-side 5xx (InternalServerError). Any sustained >0 is an AWS-side incident. | | **Tables Without PITR Enabled** | Protect revenue | Merchant rule | Count of tables where DescribeContinuousBackups.PointInTimeRecoveryStatus != ENABLED. Any production table without PITR is a data-loss risk. | | **Throttle Rate %** | Run operations | Alert band 0.1 / 1 | ThrottledRequests / (ThrottledRequests + successful requests). DynamoDB-distinctive - anything >1% means customers are seeing ProvisionedThroughputExceededException. | | **Throttled Requests (5m)** | Run operations | Merchant rule | Sum of ThrottledRequests across all tables. DynamoDB-distinctive - the #1 incident signal; any sustained >0 means requests are being rejected. | | **Throttled Requests Spike (any table)** | Run operations | Merchant rule | DynamoDB-distinctive - throttling means requests rejected; surface the offending table / GSI immediately. | | **Throttling on Cart/Inventory Table During Checkout** | Protect revenue | Merchant rule | DynamoDB-distinctive XC - the cart / session / inventory table throttling during checkout is revenue lost to capacity, not code. | | **Write Throttle Events (24h)** | Run operations | Merchant rule | Sum of WriteThrottleEvents. Writes throttle faster than reads on hot partitions. | | **Consumed Capacity Spike vs Ecom Order Rate** | Protect revenue | Merchant rule | Description pending editorial review; the signal is live. | | **Account Capacity Utilisation %** | Run operations | Alert band 70 / 90 | AccountProvisionedReadCapacityUtilization - how close the account is to its DescribeLimits quota. | | **Active Tables** | Run operations | Watch only | Count of tables in ACTIVE status from ListTables / DescribeTable. | | **Conditional Check Failures (1h)** | Protect revenue | Merchant rule | ConditionalCheckFailedRequests - DynamoDB-distinctive; a spike often signals an optimistic-locking contention storm. | | **DynamoDB Products Table vs Ecom Catalog Size** | Protect revenue | Merchant rule | DynamoDB-distinctive XC - many headless storefronts hold the product catalog in DynamoDB; item-count drift = sync failure. | | **Global Table Replicas (state)** | Control risk and change | Watch only | From DescribeGlobalTableSettings - replica region + ReplicaStatus. Gated on global tables being configured. | | **Last On-Demand Backup (hours ago)** | Run operations | Alert band 24 / 72 | Newest on-demand backup CreationDateTime from ListBackups. PITR covers continuous recovery; on-demand backups are the explicit snapshot trail. | | **Latency p95 by Operation** | Customer experience | Watch only | SuccessfulRequestLatency p95 broken out by Operation dimension (GetItem / Query / Scan / PutItem / ...). | | **On-Demand Consumed Units (24h)** | Run operations | Merchant rule | Consumed RCU+WCU on PAY\_PER\_REQUEST tables - proxy for on-demand spend (cost surface; precise \$ needs Cost Explorer / CUR). | | **Table Storage (Top 10 by size)** | Run operations | Watch only | TableSizeBytes from DescribeTable (approximate, \~6h lag). Drives storage cost. | | **Throttle Events by Table (Top 10)** | Run operations | Merchant rule | ThrottledRequests grouped by TableName dimension - pinpoints the offending table / GSI. | | **User Errors (4xx, 5m)** | Control risk and change | Merchant rule | UserErrors - client-side 4xx (validation, access-denied). Spike = a bad deploy hitting the table wrong. | ## 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 | | **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 | ### Build your own automated fixes 7 checks report findings on Amazon DynamoDB 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 **9 write** operations across cloudwatch:getmetricdatas, cloudwatch:listmetrics, describecontinuousbackups, describeglobaltablesettings, describelimits, describetables on Amazon DynamoDB. 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=dynamodb) | Resource | Read operations | Write operations | | --------------------------- | --------------- | ---------------- | | cloudwatch:getmetricdatas | 0 | 1 | | cloudwatch:listmetrics | 0 | 1 | | describecontinuousbackups | 0 | 1 | | describeglobaltablesettings | 0 | 1 | | describelimits | 0 | 1 | | describetables | 0 | 1 | | listbackups | 0 | 1 | | listglobaltables | 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 DynamoDB 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.*