Snowflake Health Score, Snowflake

​

At a glance

A single 0 to 100 composite that answers “is my Snowflake account healthy right now?” without making a platform lead read six dashboards. It folds the things that actually degrade a Snowflake account into one gauge: query latency, query errors, warehouse saturation and queueing, credit-burn sanity, replication health, and backup (Time Travel) currency. Each pillar scores 0 to 1; the score is their product, scaled to 100. Because it is multiplicative, any single pillar collapsing drags the whole score down hard, which is the point: one runaway credit burn or one stalled replication target is an emergency even if everything else is green. Read it as a traffic light: green is steady-state, amber means one pillar is wobbling, red means act now. The 7-day trend line turns a slow drift (creeping queue depth, a standby falling steadily behind) into something visible before it becomes an incident.

​

Calculation

health = latency_factor
       × error_free_factor
       × capacity_factor
       × cost_sanity_factor
       × replication_factor
       × recoverable_factor

score  = round(health × 100)

• latency factor reads p95 query execution time from QUERY_HISTORY. At or below the healthy threshold it scores 1.0; it decays towards 0 as p95 climbs past the alert level (5,000 ms by default; note Snowflake reports execution time in milliseconds in the view).
• error-free factor reads the rolling query error rate from QUERY_HISTORY (execution_status = 'FAIL' over total). Zero errors scores 1.0; it decays as the rate rises past the 1% alert level.
• capacity factor reads warehouse saturation from WAREHOUSE_LOAD_HISTORY and sustained queue depth from QUEUED_OVERLOAD_TIME. Comfortable headroom with an empty queue scores 1.0; it decays as warehouses run at 100% with queries queueing.
• cost-sanity factor reads 24-hour credit burn against its expected band. Burn inside the normal range scores 1.0; a sudden runaway (the +50% pattern) decays it, because uncontrolled spend is an account-health problem, not just a finance one.
• replication factor reads cross-account replication lag. Sub-threshold lag with a reachable target scores 1.0; lag growth decays it, and an unreachable target collapses it.
• recoverable factor reads Time Travel snapshot age. Within retention scores 1.0; it decays as the effective recovery floor ages past the threshold (72 hours by default).

​

Worked example

1. Capacity is a joint-dominant drag (0.58). BI_WH is saturated with a sustained queue. Open Warehouse Saturation % and Avg Query Queue Depth per Warehouse. The fix is to add a cluster (multi-cluster scale-out for the concurrency) rather than scale up, since the problem is many queued queries, not one giant query.
2. Cost sanity is the other dominant drag (0.62). The burn is up because the warehouse is pinned. This will self-resolve once the queue clears, but if the reporting run is recurring, schedule it off-peak. Cross-check Credits Burned (24h).
3. Latency is a symptom, not a cause (0.80). It is high because of queueing; fix capacity and latency follows. Do not chase it independently.

Why the score is 28, not "averaged" to 83:
  Multiplicative:  0.80 × 0.99 × 0.58 × 0.62 × 1.00 × 1.00 = 0.28 → 28  (honest)
  If it were a mean: (0.80+0.99+0.58+0.62+1.00+1.00)/6     = 0.83 → 83  (misleading)
  The 0.58 capacity factor would have been hidden by averaging.

1. A low score names the broken pillar; the drill-down tells you which one. Never act on the composite alone. Open the factor breakdown, find the factor nearest 0, and start there. The lowest factor is your highest-leverage fix.
2. The score is multiplicative on purpose. One collapsed pillar should cap the whole score, because in production one collapsed pillar (a runaway burn, a dead DR target) is an emergency regardless of how healthy everything else is.
3. Storage lives outside the composite. Storage growth is excluded so it cannot be masked. A 99 score with storage compounding 25% month on month is still a rising bill; always read this hero card next to Storage Used (TB).

​

Sibling cards to reference together

​

Reconciling against the source

There is no single native command that produces this score; it is a Vortex IQ composite. To reconcile it, verify each pillar against its own source: latency: SELECT APPROX_PERCENTILE(execution_time, 0.95) FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY WHERE start_time >= DATEADD('hour', -1, CURRENT_TIMESTAMP()); error rate: SELECT COUNT_IF(execution_status='FAIL') / COUNT(*) FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY WHERE start_time >= DATEADD('hour', -1, CURRENT_TIMESTAMP()); capacity / queue: SELECT warehouse_name, AVG(avg_queued_load) FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_LOAD_HISTORY WHERE start_time >= DATEADD('hour', -1, CURRENT_TIMESTAMP()) GROUP BY 1; cost sanity: SELECT SUM(credits_used) FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY WHERE start_time >= DATEADD('hour', -24, CURRENT_TIMESTAMP()); replication: SHOW REPLICATION DATABASES; and SELECT * FROM TABLE(INFORMATION_SCHEMA.REPLICATION_USAGE_HISTORY()); for lag. Managed console: Snowsight’s Admin -> Cost Management and the Query History and Warehouses pages cover the same pillars. Each native view maps to one factor.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre