Skip to main content
Card class: Hero • Category: Performance

​
At a glance

Slow-Query Rate % is the share of queries in the window whose total elapsed time crossed the “slow” threshold, expressed as a percentage of all queries that ran. It answers a question a single latency percentile cannot: not “how slow is my worst query?” but “what fraction of my workload is painful right now?” For a platform team, a creeping slow-query rate is the early tremor before a saturation incident: warehouses starting to queue, a partner pushing unbounded scans, or a stats-stale table forcing full scans where a prune should have happened.
What it tracksThe percentage of completed queries in the window whose elapsed time exceeded the slow-query threshold, over the total completed query count.
Data sourcedetail: Slow-Query Rate % for the selected period. Computed from QUERY_HISTORY (TOTAL_ELAPSED_TIME, EXECUTION_STATUS) in the ACCOUNT_USAGE share, optionally enriched by the live INFORMATION_SCHEMA.QUERY_HISTORY table function for the recent window.
Time window1h (rolling one-hour window).
Alert trigger> 5%. More than one query in twenty running slow over a sustained hour pages the platform on-call.
Why it mattersA rising slow-query rate degrades every consumer at once: dashboards time out, scheduled jobs overrun, and queue depth builds. It is a leading indicator of warehouse saturation and of inefficient or runaway SQL that also burns credits.
Rolesowner, platform, SRE

​
Calculation

The card divides the count of slow queries by the count of all completed queries in the rolling hour and multiplies by 100: 
slow_query_rate_pct = ( slow_queries / total_completed_queries ) * 100

where slow_query = a query whose TOTAL_ELAPSED_TIME >= slow_threshold
TOTAL_ELAPSED_TIME in QUERY_HISTORY is the full wall-clock duration of the query: compilation, queueing (provisioning and overload), and execution combined. The card uses elapsed rather than execution-only time on purpose, because a query that “executed” in 2s but sat queued for 40s is slow from the consumer’s point of view; queue time is part of the user’s pain. The slow threshold is configurable per profile in the Sensitivity tab; for Snowflake analytics workloads it is commonly set in the multi-second range (Snowflake latency is naturally measured in seconds, not milliseconds), so the default should be tuned to your workload shape rather than borrowed from an OLTP database. Two filters keep the denominator honest. First, only queries with a terminal EXECUTION_STATUS of SUCCESS or FAIL count; queries still running or in BLOCKED state are excluded so the live tail does not skew the ratio. Second, system and metadata queries (cache-only lookups, SHOW/DESCRIBE, results-reuse hits with zero scan) are excluded where the engine can identify them, because counting near-instant metadata calls in the denominator would mask a genuinely degrading analytical workload. The result is a rate that reflects the queries a human or a job actually waited on.

​
Worked example

A data platform team supports a BI estate where roughly 1,200 queries run per hour against the BI_WH (Medium) and LOAD_WH (Large) warehouses. Their slow threshold is set to 30 seconds, alert at > 5%. Snapshot taken on 22 Apr 26 at 14:00 BST.
HourTotal queriesSlow (>=30s)Slow-query rateState
12:00 to 13:001,190211.8%healthy
13:00 to 14:001,240342.7%healthy
14:00 to 15:001,265967.6%alert
At 14:00 the rate jumps to 7.6% and Nerve Centre pages. Latency percentiles alone would have been ambiguous (the p95 moved only modestly), but the rate makes it obvious that a large slice of the workload is now slow. 
Diagnosis trail:
  - QUERY_HISTORY for the alert hour, ordered by TOTAL_ELAPSED_TIME:
      72 of the 96 slow queries hit BI_WH and share a query_text
      pattern: SELECT ... FROM ORDERS o JOIN ORDER_LINES l ... (no date filter)
  - QUEUED_OVERLOAD_TIME is non-zero on most of them: BI_WH is queueing.
  - Root cause: a partner embedded-analytics release shipped a dashboard
    tile with an unbounded full-table join; it fires for every viewer and
    pins BI_WH at full concurrency, queueing everything behind it.

Impact while rate = 7.6%:
  - Scheduled 14:15 finance refresh on BI_WH overran by 9 minutes.
  - Two analyst dashboards timed out at the 5-minute client limit.
  - Credit burn on BI_WH up ~30% for the hour vs the prior baseline.
The fix is two-layered. Immediately, the team moves the offending dashboard to a dedicated EMBED_WH so it can no longer starve BI_WH, and the slow-query rate on BI_WH falls back to 2.4% within the next window. Structurally, they push the partner to add a date predicate so the tile prunes by micro-partition instead of full-scanning, which removes the slow queries entirely rather than just isolating them. Three takeaways for the team:
  1. Rate catches breadth; percentiles catch depth. p95/p99 tell you how bad the worst queries are; slow-query rate tells you how widespread the pain is. A small number of catastrophic queries can leave the rate low; this card is the “how much of my workload hurts” view.
  2. Queue time counts as slow. Because the metric uses elapsed (not execution) time, warehouse queueing inflates the rate directly. A jump in slow-query rate with no change in scanned bytes points at saturation, not bad SQL.
  3. Isolation buys time; pruning fixes it. Moving a noisy workload to its own warehouse stops it starving others, but the credits still burn. The durable fix is making the query prune properly.

​
Sibling cards

CardWhy pair it with Slow-Query RateWhat the combination tells you
Query Latency p95 (ms)Depth view: how slow is the slow tail?Rate up with p95 flat means many mildly-slow queries; rate up with p95 up means the tail is also degrading.
Query Latency p99 (ms)The extreme tail.A few monster queries can spike p99 while the rate stays low.
Avg Query Queue Depth per WarehouseConfirms whether slow equals queued.High rate plus high queue depth equals a saturation problem, not a SQL problem.
Warehouse Saturation %The capacity read behind the slowness.Saturated warehouse plus high slow-query rate equals upsize or multi-cluster.
Top 10 Slowest QueriesThe named offenders behind the rate.Use it to find the exact query texts inflating the percentage.
Avg Cost per Query ($)Slow queries usually cost more.A rising slow-query rate often drags cost-per-query up in lockstep.
Query Error Rate %Slow can tip into failed (timeouts).Rate climbing then errors appearing means queries are now timing out.

​
Reconciling against the source

Where to look in Snowflake’s own tooling:
Query SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY filtering on START_TIME within your hour and TOTAL_ELAPSED_TIME >= threshold, divided by total rows, to recompute the rate by hand. For the recent window with no ACCOUNT_USAGE delay, use the INFORMATION_SCHEMA.QUERY_HISTORY table function. In Snowsight, open Monitoring to Query History, filter by duration and warehouse, and sort by total duration to see the slow set directly.
Why our number may legitimately differ from Snowflake’s view:
ReasonDirectionWhy
ACCOUNT_USAGE latencyVortex IQ may lagACCOUNT_USAGE.QUERY_HISTORY is delayed up to ~45 minutes; the card blends it with the live INFORMATION_SCHEMA table function, so a same-instant ACCOUNT_USAGE recompute can differ.
Threshold definitionVariableYour manual query uses whatever cutoff you type; the card uses the profile’s configured slow threshold. Match them before comparing.
Denominator filteringVortex IQ rate may be higherThe card excludes metadata/cache-only queries from the denominator; a naive COUNT(*) over all rows includes them and dilutes the rate.
Time zoneWindow edges shiftSnowflake displays in account/session timezone; Vortex IQ renders your profile timezone. Compare on UTC instants.
Elapsed vs executionVortex IQ may be higherThe card counts queue time as part of “slow”; a query filtered only on EXECUTION_TIME would miss queue-bound slowness.

​
Known limitations / FAQs

What counts as a “slow” query? A completed query whose TOTAL_ELAPSED_TIME (compile plus queue plus execute) is at or above the slow threshold configured for your profile. Because Snowflake latency is naturally in the seconds range for analytics, the default threshold is set in seconds, not milliseconds. Tune it in the Sensitivity tab to your workload; an OLTP-style cutoff will flag almost everything. My p95 looks fine but the slow-query rate is high. How? The two answer different questions. p95 reports the duration at the 95th percentile (depth of the tail); the rate reports how large a fraction crossed your line (breadth). Many queries clustered just over the threshold raise the rate while leaving p95 only mildly elevated. Read both: rate for breadth, percentiles for depth. Does queue time inflate this number? Yes, deliberately. The metric uses elapsed time, which includes provisioning and overload queue time. A query that executed quickly but waited 40s in a queue is slow from the consumer’s perspective, so it counts. If your rate jumps with no change in scanned data, suspect warehouse saturation and check Avg Query Queue Depth per Warehouse. Why exclude metadata and cache-only queries from the denominator? A workload can fire thousands of near-instant SHOW, DESCRIBE, and results-reuse calls. Counting them in the denominator would mathematically suppress the rate and hide a genuinely degrading analytical workload behind a wall of trivial calls. The card focuses the ratio on queries someone actually waited on. The rate spiked for one hour then returned to normal. Was it a real problem? Often yes, but transient. A single bad dashboard release, an ad-hoc unbounded scan, or a one-off bulk load can spike the rate for an hour. The card’s job is to make that spike visible so you can decide whether it is a one-off or a pattern. Use Top 10 Slowest Queries for the hour to identify whether it was a recurring query text. Can a high slow-query rate cost me money even if nothing fails? Yes. Slow queries hold compute longer and often scan more, both of which burn credits, and queueing keeps warehouses running at full tilt. A sustained high rate usually shows up as elevated Avg Cost per Query ($) and Credits Burned (24h). Performance and cost move together here. Does results caching skew the rate downward? It can, in your favour, and that is accurate. A query served entirely from the results cache returns in milliseconds and is genuinely fast for the user, so excluding or fast-counting it is correct. The risk is the opposite: if cache hit rates fall (for example after a data load invalidates results), previously fast queries re-run cold and the slow-query rate can rise even though no SQL changed.

​
Tracked live in Vortex IQ Nerve Centre

Slow-Query Rate % is one of hundreds of KPI pulses Vortex IQ tracks across Snowflake and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.