> ## 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. # Google Firestore on Vortex IQ > Monitor Google Firestore health, cost and reliability signals, and catch incidents and runaway spend early. Monitor Google Firestore 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) | **24** | **7** | **Build your own** | **Ready to build yours** | **5** | | ------------------- | ---------------- | ------------------ | ------------------------ | -------------- | | performance signals | automated checks | automated fixes | workflows | API operations | ## Monitor performance 24 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 | | ----------------------------------------------------- | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **API Request Error Rate %** | Control risk and change | Alert band 0.1 / 1 | api/request\_count filtered by response\_code != OK over total requests. | | **API Request Error Rate Spike (>1% in 5m)** | Control risk and change | Alert band 0.1 / 1 | Alerts for API Request Error Rate Spike (>1% in 5m). | | **API Request Latency p95 (ms)** | Customer experience | Alert band 50 / 200 | 95th percentile of api/request\_latencies distribution (receive → finish-send). | | **Active Realtime Connections** | Run operations | Watch only | network/active\_connections - concurrent SDK / realtime connections to the database. | | **Document Operations per Second (live)** | Run operations | Watch only | read\_ops\_count + write\_ops\_count + delete\_ops\_count rate from Cloud Monitoring. | | **Document Reads (24h)** | Run operations | Watch only | document/read\_ops\_count summed over 24h - Firestore bills per document read. | | **Firestore Health Score** | Control risk and change | Merchant rule | Composite of latency, error rate, op trend and index health. | | **Firestore Op Spike vs Ecom Order Rate** | Protect revenue | Merchant rule | Firestore bills per read - a read spike with no order spike burns money for nothing. | | **Firestore Products Collection vs Ecom Catalog** | Protect revenue | Merchant rule | Firestore-distinctive XC - many headless storefronts keep the catalog in Firestore; drift = sync failure. | | **High-Latency Requests During Checkout Window (5m)** | Protect revenue | Merchant rule | High-Latency Requests During Checkout Window (5m), broken down by row. | | **Index Builds In Progress** | Run operations | Merchant rule | Firestore-distinctive - composite indexes in CREATING state. A build stuck many hours blocks the queries that need it. | | **Index in NEEDS\_REPAIR / ERROR or Build Stuck** | Control risk and change | Merchant rule | Alerts for Index in NEEDS\_REPAIR / ERROR or Build Stuck. | | **Indexes in NEEDS\_REPAIR / ERROR** | Control risk and change | Merchant rule | Composite indexes in NEEDS\_REPAIR / ERROR state - queries depending on them fail at runtime. | | **Realtime Connections vs Traffic Burst** | Protect revenue | Merchant rule | Realtime Connections vs Traffic Burst, broken down by row. | | **Request Latency p95 >200ms Sustained** | Run operations | Alert band 0 / 1 | Alerts for Request Latency p95 >200ms Sustained. | | **Slow-Query Rate %** | Customer experience | Alert band 1 / 5 | Share of api/request\_latencies samples over 200ms, computed from the metric's raw DISTRIBUTION bucketCounts (Cloud Monitoring, ALIGN\_DELTA/unaggregated) - not interpolate | | **API Request Latency p99 (ms)** | Customer experience | Alert band 100 / 500 | Description pending editorial review; the signal is live. | | **Active Snapshot Listeners** | Run operations | Watch only | network/snapshot\_listeners - Firestore-distinctive realtime listener count (onSnapshot subscriptions). | | **Document Writes (24h)** | Run operations | Watch only | document/write\_ops\_count summed over 24h. | | **Highest-Latency Request Shapes (top 10)** | Customer experience | Watch only | api/request\_latencies grouped by api\_method + collection group. | | **Point-in-Time Recovery Window (hours)** | Run operations | Alert band 24 / 72 | PITR retention from pointInTimeRecoveryEnablement (7d on Enterprise). No PITR = no rollback path on bad writes. | | **Read:Write Op Ratio** | Customer experience | Watch only | read\_ops\_count / write\_ops\_count. Firestore-distinctive - a sudden read spike vs writes = unindexed query fan-out or listener amplification. | | **Stored Bytes** | Run operations | Watch only | Estimated stored bytes (documents + index entries). Firestore bills per GB-month. | | **Total Document Count** | Run operations | Watch only | document/count across the database - drives storage cost. | ## 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 Google Firestore 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 **5 read** and **0 write** operations across projectdatabas, projectdatabascollectiongroupfields, projectdatabascollectiongroupindexes, projectdatabasoperations, projecttimeserys on Google Firestore. 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=firestore) | Resource | Read operations | Write operations | | ------------------------------------ | --------------- | ---------------- | | projectdatabas | 1 | 0 | | projectdatabascollectiongroupfields | 1 | 0 | | projectdatabascollectiongroupindexes | 1 | 0 | | projectdatabasoperations | 1 | 0 | | projecttimeserys | 1 | 0 | Signed-in users see the full catalogue in the workflow builder, filtered to the sources they have connected. ### Ready to build your first Google Firestore 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.*