30
performance signals
7
automated checks
0
prepared fixes
0
proven workflows
9
API operations
- Overview
- Monitor (30)
- Audit (7)
- Automate
What you can achieve
Capabilities are grouped around merchant outcomes, not API terminology.Run operations
Monitor orders, fulfilment, delivery and settlement.
Control risk and change
Keep tracking, access and change under governed control.
Customer experience
Find storefront, speed, accessibility and journey problems.
Protect revenue
Find failures, leaks and risks before they cost sales.
From connection to verified outcome
The controlled sequence every capability follows. Nothing changes a connected system without the approval step.1
Connect
Authorise the source. Scopes are shown before access is granted.
2
Monitor
Watch the signals against your own baselines, not universal defaults.
3
Detect
Run checks and gather evidence specific to your store.
4
Recommend
Explain what happened, why it matters and the proposed action.
5
Approve
You review scope, risk and reversibility before anything changes.
6
Execute
Apply through governed connector operations.
7
Verify
Confirm the intended result and keep the receipt.
Monitor performance
30 performance signals. Open an outcome to see its signals and how each one alerts. Read-only operations do not modify the connected system.Run operations (14 signals)
Run operations (14 signals)
| Signal | Alert behaviour | What it tracks |
|---|---|---|
| Account Capacity Utilisation % | Alert band 70 / 90 | AccountProvisionedReadCapacityUtilization - how close the account is to its DescribeLimits quota. |
| Active Tables | Watch only | Count of tables in ACTIVE status from ListTables / DescribeTable. |
| Consumed Capacity (RCU+WCU, live) | Watch only | ConsumedReadCapacityUnits + ConsumedWriteCapacityUnits Sum over the last minute. |
| Last On-Demand Backup (hours ago) | Alert band 24 / 72 | Newest on-demand backup CreationDateTime from ListBackups. PITR covers continuous recovery; on-demand backups are the explicit snapshot trail. |
| On-Demand Consumed Units (24h) | Merchant rule | Consumed RCU+WCU on PAY_PER_REQUEST tables - proxy for on-demand spend (cost surface; precise $ needs Cost Explorer / CUR). |
| Provisioned Capacity at >80% Utilisation | Alert band 0 / 1 | Alerts for Provisioned Capacity at >80% Utilisation. |
| Provisioned Write Utilisation % | Alert band 70 / 90 | ConsumedWriteCapacityUnits / ProvisionedWriteCapacityUnits (PROVISIONED tables). |
| Read Throttle Events (24h) | Merchant rule | Sum of ReadThrottleEvents. Spike = under-provisioned reads or a hot partition. |
| Table Storage (Top 10 by size) | Watch only | TableSizeBytes from DescribeTable (approximate, ~6h lag). Drives storage cost. |
| Throttle Events by Table (Top 10) | Merchant rule | ThrottledRequests grouped by TableName dimension - pinpoints the offending table / GSI. |
| Throttle Rate % | Alert band 0.1 / 1 | ThrottledRequests / (ThrottledRequests + successful requests). DynamoDB-distinctive - anything >1% means customers are seeing ProvisionedThroughput |
| Throttled Requests (5m) | 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) | Merchant rule | DynamoDB-distinctive - throttling means requests rejected; surface the offending table / GSI immediately. |
| Write Throttle Events (24h) | Merchant rule | Sum of WriteThrottleEvents. Writes throttle faster than reads on hot partitions. |
Control risk and change (6 signals)
Control risk and change (6 signals)
| Signal | Alert behaviour | What it tracks |
|---|---|---|
| DynamoDB Health Score | Merchant rule | Composite of throttle rate, error rate, latency p95 and capacity utilisation. |
| Global Table Replicas (state) | Watch only | From DescribeGlobalTableSettings - replica region + ReplicaStatus. Gated on global tables being configured. |
| Global Table Replication Lag (seconds) | Alert band 1 / 10 | CloudWatch ReplicationLatency for global tables, converted to seconds. Gated - only meaningful when global tables are configured. |
| System Error (5xx) Spike | Merchant rule | Alerts for System Error (5xx) Spike. |
| System Errors (5xx, 5m) | Merchant rule | SystemErrors - DynamoDB-side 5xx (InternalServerError). Any sustained >0 is an AWS-side incident. |
| User Errors (4xx, 5m) | Merchant rule | UserErrors - client-side 4xx (validation, access-denied). Spike = a bad deploy hitting the table wrong. |
Protect revenue (6 signals)
Protect revenue (6 signals)
| Signal | Alert behaviour | What it tracks |
|---|---|---|
| Conditional Check Failures (1h) | Merchant rule | ConditionalCheckFailedRequests - DynamoDB-distinctive; a spike often signals an optimistic-locking contention storm. |
| Consumed Capacity Spike vs Ecom Order Rate | Merchant rule | Description pending editorial review; the signal is live. |
| DynamoDB Products Table vs Ecom Catalog Size | Merchant rule | DynamoDB-distinctive XC - many headless storefronts hold the product catalog in DynamoDB; item-count drift = sync failure. |
| Provisioned Read Utilisation % | Alert band 70 / 90 | ConsumedReadCapacityUnits / ProvisionedReadCapacityUnits (PROVISIONED tables). >80% sustained = throttle risk; check auto-scaling. |
| Tables Without PITR Enabled | Merchant rule | Count of tables where DescribeContinuousBackups.PointInTimeRecoveryStatus != ENABLED. Any production table without PITR is a data-loss risk. |
| Throttling on Cart/Inventory Table During Checkout | Merchant rule | DynamoDB-distinctive XC - the cart / session / inventory table throttling during checkout is revenue lost to capacity, not code. |
Customer experience (4 signals)
Customer experience (4 signals)
| Signal | Alert behaviour | What it tracks |
|---|---|---|
| GetItem Latency p95 (ms) | Alert band 50 / 200 | SuccessfulRequestLatency p95 with Operation=GetItem. DynamoDB targets single-digit ms - p95 over baseline is a real regression. |
| Latency p95 by Operation | Watch only | SuccessfulRequestLatency p95 broken out by Operation dimension (GetItem / Query / Scan / PutItem / …). |
| Query Latency p99 (ms) | Alert band 100 / 500 | SuccessfulRequestLatency p99 with Operation=Query. |
| Slow-Query Rate % | Alert band 1 / 5 | CloudWatch Percentile Rank (Stat=PR(200:)) on SuccessfulRequestLatency - the % of samples above 200ms, computed server-side by CloudWatch from the und |
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. Open a check for the detail.Connection pool saturation above 90%
Connection pool saturation above 90%
Severity critical · Outcome Customer experience · Fix status Report onlyAt 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, including new customer sessions and checkout, starts failing, not just slowing down.Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.Reference:
DB-CAP-001Disk usage above 90%
Disk usage above 90%
Severity critical · Outcome Run operations · Fix status Report onlyA 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 slower. There is very little runway left at 90%.Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.Reference:
DB-CAP-002Query error rate above 1% in last 5 minutes
Query error rate above 1% in last 5 minutes
Severity critical · Outcome Run operations · Fix status Report onlyMore 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 silently dropping work, and a rate this high in a 5-minute window is an active incident, not background noise.Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.Reference:
DB-ERR-001Last successful backup older than 72 hours
Last successful backup older than 72 hours
Severity high · Outcome Run operations · Fix status Report onlyIf 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 would be unrecoverable in a real incident, not just delayed.Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.Reference:
DB-BAK-001Replication lag above 10 seconds
Replication lag above 10 seconds
Severity high · Outcome Run operations · Fix status Report onlyAnything 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 replica is also that far behind on failover, which is a bigger problem than the staleness alone.Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.Reference:
DB-REP-001Slow-query rate above 5% of total
Slow-query rate above 5% of total
Severity high · Outcome Customer experience · Fix status Report onlyMore 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 database is paying the slow-query cost, not just an unlucky occasional request.Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.Reference:
DB-PERF-002p95 query latency above 200ms sustained 15m
p95 query latency above 200ms sustained 15m
Severity high · Outcome Customer experience · Fix status Report onlyOne 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 database inherits that slowness directly, and a sustained p95 this high is usually already visible to customerVortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.Reference:
DB-PERF-001Build your own automated fixes
Turn any finding into an automated fix with a Vortex IQ workflow: over 13,000 read and write operations across more than 200 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 over 13,000 operations across more than 200 connectors to automate the work in your own words.Changes follow your configured approval policy: the target, proposed change, affected records, risk, reversibility and verification plan are shown before execution.Create a workflowReady 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.Browse the operations you can build with
Browse the operations you can build with
| 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 |