Query Latency p95 (ms), Snowflake

​

At a glance

Query Latency p95 (ms) is the 95th-percentile end-to-end execution time across all queries in the window: 95% of queries finish faster than this number, and the slowest 5% are above it. It is the most useful single read on the experience your heaviest, most-watched workloads feel, because dashboards and scheduled loads tend to sit in that upper tail. The median (p50) can look healthy while the p95 is quietly punishing your biggest reports. One important Snowflake-specific note: Snowflake reports query latency natively in seconds in most of its console views, not milliseconds, so the threshold here (5000ms equals 5 seconds) reflects an analytics use case where multi-second queries are normal, unlike a transactional database where 5 seconds would be catastrophic.

​

Calculation

​

Worked example

1. The median is fine, so this is a tail problem, not a whole-distribution problem. p50 moved 30ms; the typical analyst worksheet still returns in half a second. The pain is concentrated in the heavy queries, the finance close dashboard tiles that scan large fact tables and the ELT models running concurrently.
2. The cause is contention, not bad SQL. Drilling into Avg Query Queue Depth per Warehouse shows the FINANCE_WH queue depth sitting at 7 sustained. The heavy dashboard queries are not slow because they are badly written; they are slow because they are waiting in line behind the ELT job on a warehouse that is too small for the concurrent close-day load.
3. The fix is a warehouse change, not a query rewrite. Options, in order of speed: enable multi-cluster scaling on FINANCE_WH so a second cluster spins up under queue pressure, or temporarily resize it from Medium to Large for the close window, or move the ELT job to its own warehouse so it stops competing with interactive dashboards.

Decomposing the 7,400ms p95:
  - Execution time (actual compute): ~3,200ms (close to baseline p95)
  - Queue + provisioning time:        ~4,200ms (the new contention)
  => More than half the p95 is queue time, confirming a sizing problem
     rather than a query-complexity problem

1. Always read p95 against p50. p95 up with p50 flat equals a tail/contention problem affecting the heavy workloads. p95 up and p50 up equals a whole-distribution shift, which points to an account-wide cause: result cache cold after a restart, statistics drift, or a broad data-volume increase.
2. p95 includes queue time, so it is half a performance metric and half a capacity metric. Decompose it (execution time vs queue time) before deciding whether to optimise the query or resize the warehouse. The Avg Query Queue Depth per Warehouse card does this split for you.
3. 5 seconds is the right alarm for analytics, not for OLTP. Snowflake is a warehouse, not a transactional store. A 5-second p95 on a transactional database would be a crisis; on an analytics warehouse running multi-table scans it is the sensible line between “normal heavy query” and “something is wrong”. Adjust in the Sensitivity tab if your workload is lighter or heavier.

​

Sibling cards to reference together

​

Reconciling against the source

Snowsight to Monitoring to Query History, then sort by Duration and read the slowest queries (Snowsight shows duration in seconds, so divide our ms by 1000 to compare). Query Profile on any individual slow query to see the execution vs queue time breakdown. SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY or the live INFORMATION_SCHEMA.QUERY_HISTORY table function for the authoritative numbers.

SELECT PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY TOTAL_ELAPSED_TIME) AS p95_ms
FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY(
  DATEADD('hour', -1, CURRENT_TIMESTAMP()), CURRENT_TIMESTAMP()));

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre