29
performance signals
9
automated checks
Build your own
automated fixes
Ready to build yours
workflows
16
API operations
- Overview
- Monitor (29)
- Audit (9)
- Automate
What you can achieve
Capabilities are grouped around merchant outcomes, not API terminology.Customer experience
Find storefront, speed, accessibility and journey problems.
Run operations
Monitor orders, fulfilment, delivery and settlement.
Protect revenue
Find failures, leaks and risks before they cost sales.
Catalogue quality
Identify missing, inconsistent or outdated product data.
Control risk and change
Keep tracking, access and change under governed control.
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
29 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 (13 signals)
Run operations (13 signals)
| Signal | Alert behaviour | What it tracks |
|---|---|---|
| Active Sessions | Watch only | COUNT of V$SESSION WHERE STATUS=‘ACTIVE’ AND TYPE=‘USER’. |
| Archive Log Apply Gap | Merchant rule | Data Guard only - sequence gap between primary archived and standby applied (V$ARCHIVED_LOG). A growing gap shrinks the recovery window. |
| Blocked Sessions | Merchant rule | VSESSIONWHEREBLOCKINGSESSIONISNOTNULL(corroboratedbyVLOCK / DBA_BLOCKERS). Long blocker chains stall the app. |
| Buffer Cache Hit Ratio % | Alert band 95 / 80 | 1 - (physical reads / (db block gets + consistent gets)) from V$SYSSTAT. Low = SGA / buffer cache undersized, data read from disk. |
| Data Guard Transport Lag (seconds) | Merchant rule | Data Guard only - ‘transport lag’ from V$DATAGUARD_STATS. Growing transport lag = redo not shipping (network / archiver stuck). |
| Instance Uptime | Watch only | SYSDATE - STARTUP_TIME from V$INSTANCE. Drop = unplanned restart / instance crash. |
| Library Cache Hit Ratio % | Merchant rule | Oracle-distinctive - GETHITRATIO from V$LIBRARYCACHE. Low = excessive hard parses (no bind variables) thrashing the shared pool. |
| Oracle Health Score | Merchant rule | Composite of wait-class health, blocking, Data Guard lag, cache hit ratios, and backup recency. <70 = investigate. |
| PGA Memory Usage % | Merchant rule | Total PGA allocated / PGA aggregate target from V$PGASTAT. Over target = work areas spilling to temp tablespace. |
| SQL Executions / Second (live) | Watch only | ’execute count’ delta from V$SYSSTAT - primary throughput signal. |
| Session Saturation % | Alert band 70 / 90 | CURRENT_UTILIZATION / LIMIT_VALUE for resource_name=‘sessions’ from V$RESOURCE_LIMIT. >90% = ORA-00018 imminent. |
| Standby Apply State | Watch only | Data Guard only - RECOVERY_MODE / managed-recovery state per standby destination from V$ARCHIVE_DEST_STATUS. |
| Tablespace Usage >90% | Alert band 70 / 90 | DBA_TABLESPACE_USAGE_METRICS - a tablespace hitting its autoextend MAXSIZE stalls every write to it (ORA-01653). |
Protect revenue (6 signals)
Protect revenue (6 signals)
| Signal | Alert behaviour | What it tracks |
|---|---|---|
| Blocking / Slow SQL During Checkout Window | Merchant rule | Blocking / Slow SQL During Checkout Window, broken down by row. |
| Failed Logins (24h) | Merchant rule | ’logon failures’ delta from V$SYSSTAT (or DBA_AUDIT_SESSION when auditing is on). Bursts = brute force or stale app credentials. |
| Oracle Load Spike vs Ecom Order Rate | Merchant rule | Description pending editorial review; the signal is live. |
| Oracle Product Table Row Count vs Ecom Catalog Size | Merchant rule | Oracle-distinctive XC - many enterprise merchants keep their product / inventory master in Oracle; row-count drift vs ecom = sync failure / oversell r |
| Oracle Session Saturation vs Traffic Burst | Alert band 70 / 90 | Oracle Session Saturation vs Traffic Burst, broken down by row. |
| Tablespace Usage % | Alert band 70 / 90 | Max used_percent across permanent tablespaces from DBA_TABLESPACE_USAGE_METRICS. >90% = autoextend exhaustion risk. |
Customer experience (4 signals)
Customer experience (4 signals)
| Signal | Alert behaviour | What it tracks |
|---|---|---|
| Avg SQL Elapsed per Exec (ms) | Alert band 50 / 200 | ELAPSED_TIME / EXECUTIONS across V$SQLSTATS. Oracle exposes per-statement averages, not native percentiles - p95/p99 derived. |
| Slow-SQL Rate % | Alert band 1 / 5 | Share of executions over the slow threshold (default 200ms) from V$SQLSTATS deltas between polls. |
| Top 10 SQL by Elapsed Time | Watch only | Ordered by ELAPSED_TIME / BUFFER_GETS from V$SQLSTATS + SQL_TEXT. The Top SQL surface DBAs tune first. |
| Top Wait Events (by wait class) | Watch only | Oracle-distinctive - VSYSTEMEVENT/VACTIVE_SESSION_HISTORY grouped by WAIT_CLASS. ‘db file sequential read’, ‘log file sync’, ‘enq: TX’ climbing = |
Catalogue quality (3 signals)
Catalogue quality (3 signals)
| Signal | Alert behaviour | What it tracks |
|---|---|---|
| Blocking Lock Chain >30s | Merchant rule | V$SESSION.BLOCKING_SESSION chain sustained - row-lock contention stalling the app. |
| Enqueue (Lock) Waits | Merchant rule | Oracle-distinctive - ‘enq: TX - row lock contention’ / ‘enq: TM’ waits from V$SYSTEM_EVENT. Climbing = lock contention building. |
| Last Successful Backup (hours ago) | Alert band 24 / 72 | MAX(COMPLETION_TIME) for a successful full / L0 backup from V$RMAN_BACKUP_JOB_DETAILS. Autonomous / RDS: automatic backups - derive from the managed b |
Control risk and change (3 signals)
Control risk and change (3 signals)
| Signal | Alert behaviour | What it tracks |
|---|---|---|
| Data Guard Apply Lag (seconds) | Alert band 1 / 10 | Data Guard only - ‘apply lag’ from V$DATAGUARD_STATS. Gated when no standby is configured. |
| Data Guard Apply Lag >10s or Standby Not Applying | Alert band 1 / 10 | Data Guard only - gated when no standby is configured. |
| User Error Rate % | Alert band 0.1 / 1 | ’user errors’ delta from V$SYSSTAT over execute count. Spikes flag failing statements / app retry storms (ORA- errors). |
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-001Buffer / cache hit rate below 80%
Buffer / cache hit rate below 80%
Severity medium · Outcome Run operations · Fix status Report onlyMore 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 one obvious failure.Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.Reference:
DB-CACHE-001Deadlocks detected (>0 in last 5 minutes)
Deadlocks detected (>0 in last 5 minutes)
Severity medium · Outcome Protect revenue · Fix status Report onlyA deadlock means two operations blocked each other and the database had to kill one of them; whatever that transaction was doing (placing an order, updating stock, writing a record) failed and, depending on how the application handles it, may not have been retried.Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.Reference:
DB-PERF-003Build 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 16 read and 0 write operations across dbatablespaceusagemetrics, varchivedeststatus,varchivedlogs, vdatabases,vdataguardstats, v$instances on Oracle Database. 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 Oracle Database 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 |
|---|---|---|
| dbatablespaceusagemetrics | 1 | 0 |
| v$archivedeststatus | 1 | 0 |
| v$archivedlogs | 1 | 0 |
| v$databases | 1 | 0 |
| v$dataguardstats | 1 | 0 |
| v$instances | 1 | 0 |
| v$librarycaches | 1 | 0 |
| v$locks | 1 | 0 |