TL;DR
Snowflake Query History is the execution record Snowflake keeps for every SQL statement, available through Snowsight (14 days), INFORMATION_SCHEMA.QUERY_HISTORY() (7 days, near real time), and ACCOUNT_USAGE.QUERY_HISTORY (365 days, up to 45 minutes delayed), and the right one to use depends on whether you need a live incident, a recent SQL check, or a year of trend data.
Key Takeaways Snowflake Query History is the execution record for every SQL statement, exposed through three surfaces: Snowsight (14 days), INFORMATION_SCHEMA.QUERY_HISTORY() (7 days, near real time), and ACCOUNT_USAGE.QUERY_HISTORY (365 days, up to 45 minutes delayed). The RESULT_LIMIT parameter in Information Schema functions applies before any outer filter, so a narrow WHERE clause on top of a small limit can silently miss matching rows further back. Query History cannot report exact per-query warehouse cost; credits_used_cloud_services covers only cloud-services credits, and summing concurrent query durations double-counts overlapping warehouse time. Grouping by query_parameterized_hash instead of raw query_text is the single most useful habit for turning thousands of literal-value variants into one trend line. Full account-wide visibility requires ACCOUNTADMIN, IMPORTED PRIVILEGES on the SNOWFLAKE database, or the GOVERNANCE_VIEWER database role; MONITOR or OPERATE on a warehouse scopes visibility to that warehouse only. Kanerika, a Snowflake Select Tier Partner, rebuilt a beverage manufacturer’s reporting layer on governed Snowflake pipelines with real cost visibility, cutting annual Snowflake spend by 28% alongside 45% faster refresh cycles. Which Query Actually Burned Through This Month’s Compute Budget? A warehouse bill lands 40% higher than last month and nobody can say why. Somewhere in the account, a query scanned terabytes it did not need to, or a dashboard refreshed every sixty seconds instead of every hour.
Query History is the only place that answer lives. It is Snowflake’s record of every statement that ran, who ran it, how long it took, and how much data it touched.
Most teams open the Snowsight history tab once, skim a few rows, and move on. That leaves most of what the data can do on the table: root-cause diagnosis, cost attribution, security auditing, and automated monitoring all run on the same underlying records.
This guide covers all three ways Snowflake exposes that data, the columns worth actually reading, and the SQL patterns that turn a wall of rows into a working monitoring practice.
Watch on YouTube
Snowflake to Microsoft Fabric Migration: Real Cost Breakdown (2026)
Kanerika breaks down the real cost mechanics behind a Snowflake platform decision, the same warehouse-credit economics that make Query History’s cost-attribution columns worth understanding.
What Is Snowflake Query History? Query History is an execution log, not a saved-query library. Every time Snowflake compiles and runs a statement, whether typed into a worksheet, sent by a BI tool, fired by a task, or issued inside a stored procedure, it writes a record: the SQL text, the user and role, the warehouse, the timing, the data scanned, and the outcome.
The name creates real confusion because Snowflake reuses it for three different things:
Snowsight Query History , the visual page under Monitoring.INFORMATION_SCHEMA.QUERY_HISTORY()SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORYQuery History is also frequently confused with things it is not. It does not store saved worksheets, and it is not the same dataset as Access History , which tracks which tables and columns a query actually touched rather than just the SQL text submitted.
It also will not hand you an exact dollar figure per query. Snowflake bills by warehouse-second, not by statement, so cost has to be estimated and allocated rather than read directly off a single row, a limitation covered in detail later in this guide.
Snowsight vs. Information Schema vs. Account Usage The three surfaces trade off retention, freshness, and access rules. Picking the wrong one is the most common reason a query “goes missing” that is actually sitting right there, just outside the window being searched.
Method Best for Retention Data delay Query Profile Snowsight (Individual Queries) Recent visual investigation 14 days Near real time Yes Snowsight (Grouped Queries) Repeated query patterns 14 days Up to 3 hours Sample profiles INFORMATION_SCHEMA functionsRecent operational SQL checks 7 days Near real time No ACCOUNT_USAGE.QUERY_HISTORYHistorical analysis, dashboards 365 days Up to 45 minutes No
Snowflake documents these retention and latency figures directly in its Snowsight activity monitoring guide and the ACCOUNT_USAGE.QUERY_HISTORY reference , and both are worth bookmarking because Snowflake has changed these numbers before.
Snowsight for recent visual investigation Under Monitoring, the Query History page lists recent statements with filters for user, warehouse, status, and time range. Clicking into a query opens Query Details and, for completed queries, the Query Profile, a visual breakdown of every operator in the execution plan.
Snowsight also splits Individual Queries from Grouped Queries. Individual Queries gives one row per statement, the fastest way to find a specific failure or a query ID someone just mentioned in Slack. Grouped Queries clusters structurally identical statements by query_parameterized_hash and shows execution count, failure rate, and p50/p90/p99 latency, which is far more useful for a BI tool firing the same parameterized query thousands of times a day.
INFORMATION_SCHEMA.QUERY_HISTORY() for near-real-time checks This table function is the right tool when a query finished thirty seconds ago and Account Usage has not caught up yet.
SELECT *
FROM TABLE(
INFORMATION_SCHEMA.QUERY_HISTORY(
END_TIME_RANGE_START => DATEADD('hour', -1, CURRENT_TIMESTAMP()),
END_TIME_RANGE_END => CURRENT_TIMESTAMP(),
RESULT_LIMIT => 1000
)
)
ORDER BY start_time DESC;Three rules trip people up here. The time range is evaluated against the requested end time, which must fall within the previous 7 days. RESULT_LIMIT is applied before any outer WHERE clause runs, so a narrow filter on top of a small limit can silently return zero rows even though matching queries exist further back in the set. Raise the limit before adding a tight filter, not after.
Snowflake also ships QUERY_HISTORY_BY_USER, QUERY_HISTORY_BY_WAREHOUSE, and QUERY_HISTORY_BY_SESSION variants, documented in the QUERY_HISTORY function reference , for the same near-real-time window scoped to one user, warehouse, or session, which is often faster to reason about than filtering the general function by hand.
QUERY_HISTORY_BY_SESSION is particularly useful for reproducing a connector or driver problem, since it returns every statement inside one session in order, including any parameter-setting statements a BI tool issued before the query that actually failed.
ACCOUNT_USAGE.QUERY_HISTORY for historical reporting This is the workhorse for anything that needs more than a week of data: trend lines, monthly cost reports, user attribution, and compliance evidence.
SELECT *
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
ORDER BY start_time DESC;It holds up to 365 days of records but can lag live activity by as much as 45 minutes, which rules it out for anything resembling an incident response dashboard. Pair it with the Information Schema functions for that use case instead.
Reading the QUERY_HISTORY Schema Without Getting Lost The view carries dozens of columns. Reading them one at a time in alphabetical order is a good way to lose an afternoon, so group them by the question each one answers.
Identity and SQL text: query_id, query_text, query_type, query_tag, and two hash fields worth knowing. query_hash matches identical SQL structure, while query_parameterized_hash groups statements whose literal values differ but whose shape is the same, which is the field almost every aggregation query in this guide relies on.
User, role, and client: user_name, role_name, session_id, and client_application_id, the fields that make user audits and BI-tool attribution possible.
Timing: total_elapsed_time is reported in milliseconds and splits into compilation_time, execution_time, queued_provisioning_time, queued_overload_time, and transaction_blocked_time. Adding these together usually gets close to the headline duration and tells you whether a slow query was actually slow to run, or just slow to start.
Scan and pruning: bytes_scanned, partitions_scanned, and partitions_total. A high ratio of scanned to total partitions is the clearest signal of weak micro-partition pruning, the same mechanic covered in Kanerika’s guide to Snowflake clustering .
Spill: bytes_spilled_to_local_storage and bytes_spilled_to_remote_storage. Local spill suggests memory pressure; remote spill is the stronger warning sign and usually means the warehouse is undersized for the join or sort it just attempted.
Cost-adjacent fields, with a warning: credits_used_cloud_services reports only the cloud-services credits tied to that statement. It is not the warehouse compute cost of the query and does not reflect the daily cloud-services adjustment Snowflake applies at billing time, a distinction covered fully in the cost section below.
One more field worth flagging: Snowflake has marked rows_produced for eventual removal because it does not reliably represent the logical row count affected by every statement type. The more specific rows_inserted, rows_updated, and rows_deleted fields are the safer choice for anything built to last.
Practical SQL for Searching and Filtering Query History A handful of patterns cover almost every real investigation. Start with the query ID when you have one, since it is the fastest and safest lookup key:
SELECT *
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE query_id = '01b2c3d4-...';Finding everything a specific user ran in the last month is the next most common request, whether for an audit, an offboarding review, or a debugging session with an analyst:
SELECT query_id, user_name, role_name, warehouse_name,
start_time, total_elapsed_time, query_text
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE user_name = 'ANALYST_USER'
AND start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
ORDER BY start_time DESC;Filtering by outcome catches failures and incidents, though canceled queries need a text match rather than a status value, since Snowflake does not give cancellation its own execution_status:
-- Failures and platform incidents
WHERE execution_status IN ('FAIL', 'INCIDENT')
-- Canceled queries specifically
WHERE error_message ILIKE '%SQL execution canceled%'Time-range filters carry a quiet trap. start_time and end_time use TIMESTAMP_LTZ, and Snowsight displays results in the viewer’s browser timezone, which does not change just because a session’s TIMEZONE parameter was set differently. A query that looks missing is often just sitting one timezone offset away from where someone is looking.
Query tags turn a wall of anonymous SQL into something a FinOps team can actually chargeback. Tagging every scheduled job, BI connection, and pipeline with a consistent format such as team=finance;app=tableau;env=prod makes this filter trivial later:
WHERE query_tag = 'FINANCE_MONTH_END'Finally, grouping by query_parameterized_hash instead of raw query_text is the single most useful habit in this whole guide, because it collapses thousands of literal-value variants of the same query into one row:
SELECT query_parameterized_hash,
COUNT(*) AS executions,
AVG(total_elapsed_time) AS avg_ms,
APPROX_PERCENTILE(total_elapsed_time, 0.95) AS p95_ms,
SUM(bytes_scanned) AS total_bytes_scanned
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
GROUP BY query_parameterized_hash
ORDER BY total_bytes_scanned DESC;These six patterns cover the large majority of ad hoc lookups a platform team runs in a given week, and every one of them works unchanged against either Information Schema or Account Usage by swapping the source.
Kanerika Service
Snowflake Consulting and Implementation
Kanerika is a Snowflake Select Tier Partner that designs monitoring, governance, and cost-attribution practices on top of Query History and Account Usage for enterprise Snowflake estates.
Explore Snowflake Services Finding Slow and Expensive Queries Diagnosing a slow query works best as a fixed sequence rather than a guess. Start with total elapsed time, then split it into phases: queue time, compilation time, execution time, and blocked time.
A query dominated by queued_provisioning_time is waiting on a warehouse to start, not running slowly at all. One dominated by queued_overload_time is competing for a warehouse that is undersized for its concurrency. Only high execution_time with low queue and compile time points at the SQL itself, which is where Kanerika’s companion guide to Snowflake query optimization takes over with the actual rewrite techniques.
Comparing a query against its own history, grouped by query_parameterized_hash, catches regressions that a single snapshot misses entirely. A query that normally runs in four seconds and now takes forty has regressed, even if forty seconds does not look alarming in isolation.
Two more patterns cover most of what is left. Ranking by queue time isolates warehouses that are undersized for their concurrency rather than queries that are genuinely slow to execute:
SELECT warehouse_name,
DATE_TRUNC('hour', start_time) AS hour_bucket,
SUM(queued_overload_time) AS total_queue_ms,
COUNT(*) AS query_count
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
GROUP BY warehouse_name, hour_bucket
HAVING SUM(queued_overload_time) > 0
ORDER BY total_queue_ms DESC;Ranking by scan efficiency surfaces queries with weak micro-partition pruning, the pattern behind most unexplained scan-volume spikes:
SELECT query_id, user_name, warehouse_name, total_elapsed_time,
partitions_scanned, partitions_total,
partitions_scanned / NULLIF(partitions_total, 0) AS scan_ratio
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
AND partitions_total > 0
ORDER BY scan_ratio DESC
LIMIT 50;Cost is a different exercise, and the biggest mistake is assuming Query History stores it directly. Snowflake bills by active warehouse-time, not per statement, and several queries commonly share the same warehouse-second. Summing total_elapsed_time across concurrent queries double-counts that overlap and overstates spend.
A defensible allocation model instead joins Query History with WAREHOUSE_METERING_HISTORY: pull warehouse credits by time bucket, identify which queries ran in each bucket, and assign a share of the bucket’s cost based on execution-time overlap. It is an estimate, not an invoice, and should be labeled that way in any dashboard built on top of it.
Auditing Who Ran What Query History is a legitimate first stop for an access audit, with one hard limit worth stating upfront: it proves a statement ran, not which columns or rows it actually touched. For that level of detail, Snowflake’s ACCESS_HISTORY view is the correct source, since it records object and column-level access rather than raw SQL text.
Within that limit, Query History still covers a lot of ground. Filtering by query_type for destructive statements catches the operations that matter most for change control:
WHERE query_type IN ('DROP', 'TRUNCATE_TABLE', 'DELETE', 'UPDATE', 'ALTER')Service accounts and application users deserve their own audit trail, using user_type, client_application_id, and session_id together to trace what an automated pipeline actually executed rather than assuming its job succeeded because the schedule says it ran.
Pair this with authn_event_id where it is available, which links a query back to the specific authentication event that started the session, useful evidence when an audit needs to show not just what ran but how the user got in.
A workable audit cadence does not require reviewing every row. A weekly pass over destructive DML grouped by user and object, plus a monthly review of service-account activity against expected schedules, catches the large majority of issues worth catching.
One governance note worth building into any audit process: query text can contain sensitive values. A literal customer ID, an email address, or an accidentally pasted token in a WHERE clause ends up stored right there in query_text, which is a real argument for restricting who can read raw SQL text even when they are allowed to see query metadata.
Checklist
Snowflake Performance Optimization Checklist
A practical checklist for keeping Snowflake queries fast and costs under control, the operational counterpart to the auditing and monitoring guidance in this guide.
Get the Checklist → Debugging Failed Queries A failure investigation almost always starts the same way: pull recent failures for a user or application, then group by error_code to separate a one-off mistake from a systemic problem hitting many users at once.
execution_status distinguishes FAIL, an ordinary SQL error, from INCIDENT, a platform-side problem Snowflake itself flags. That distinction alone often tells a team whether to fix a query or open a support case.
Syntax errors sometimes show as <redacted> in query_text. Viewing the full text requires the relevant privilege plus the account parameter that enables unredacted syntax-error text, a deliberate Snowflake safeguard against leaking sensitive literals from a query that never even compiled.
For nested execution, such as a stored procedure calling several statements, parent_query_id and root_query_id let you trace the full chain back to the original call, which is usually faster than reading procedure logic line by line to guess what ran.
Blocked and retried queries need their own check, since they rarely show up as an outright failure. A query stuck behind a lock still records a completed status once the lock clears, so the delay only shows up in the timing columns:
SELECT query_id, user_name, warehouse_name, query_retry_cause,
transaction_blocked_time, query_retry_time
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
AND (transaction_blocked_time > 0 OR query_retry_time > 0)
ORDER BY transaction_blocked_time + query_retry_time DESC;A high count of retried queries sharing the same query_hash and warehouse is usually a memory-pressure signal, and worth cross-checking against the spill columns before assuming a bigger warehouse is the fix rather than a query rewrite.
Talk to Kanerika
Building a Query History Monitoring Practice?
Kanerika scopes the tags, roles, and dashboards a real monitoring practice needs, then builds it against your actual workload mix instead of a generic template.
Schedule a Demo → Query History Permissions and RBAC Every user can see their own query history by default, no special grant required. Seeing anyone else’s requires one of a small number of paths.
MONITOR or OPERATE on a warehouse lets a role see every query that ran on that specific warehouse, regardless of who submitted it, which is the narrowest and often most appropriate grant for a team lead who only needs visibility into their own warehouse.
Account-wide visibility requires ACCOUNTADMIN, IMPORTED PRIVILEGES on the SNOWFLAKE database, or the GOVERNANCE_VIEWER database role, which covers direct ACCOUNT_USAGE SQL access and Grouped Queries in Snowsight but, on its own, does not surface every other user’s Individual Queries in the Snowsight UI.
Handing out ACCOUNTADMIN just to power a dashboard is a common shortcut and a poor one. It grants far more than monitoring requires, weakens accountability, and turns one exposed credential into an account-wide risk.
A dedicated monitoring role built around GOVERNANCE_VIEWER plus targeted warehouse grants covers the same reporting needs with a much smaller blast radius, an approach Kanerika applies as standard practice in its data governance engagements . A practical starting point:
CREATE ROLE QUERY_MONITOR_ROLE;
GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE QUERY_MONITOR_ROLE;Add warehouse-level MONITOR grants on top of this role only where a team genuinely needs live visibility into a specific warehouse, rather than reaching for account-wide access by default.
Query History vs. Access History vs. Task History Each of Snowflake’s account-usage views answers a different question, and mixing them up wastes real investigation time.
Question Correct source Who ran this SQL, and how long did it take? QUERY_HISTORY Which tables and columns did it actually read? ACCESS_HISTORY Why did this scheduled task fail? TASK_HISTORY + QUERY_HISTORY How many warehouse credits were billed? WAREHOUSE_METERING_HISTORY How did the user authenticate and connect? LOGIN_HISTORY
None of these views substitute for each other, and the most common investigation mistake is reaching for Query History when the real question belongs to one of the other four. A cost question answered from Query History alone will always be an estimate; the same question answered from Warehouse Metering History is closer to what actually gets billed.
Building a habit of naming the right source before writing any SQL saves real investigation time. A five-minute detour through the wrong view, followed by the realization that the fields simply are not there, happens often enough that this table is worth keeping open in a second tab during any serious debugging session.
TASK_HISTORY tracks the scheduling layer, whether a task fired on time and what state it ended in, while the underlying SQL it triggered still lives in Query History; debugging a failed pipeline usually means joining the two. Kanerika’s guide to data engineering covers where task orchestration fits into a broader pipeline design.
Limitations and Gotchas Worth Remembering A short list of behaviors causes most of the confusion teams run into after the first few weeks of using Query History seriously.
Each interface has its own retention window: 7 days, 14 days, or 365 days, and mixing them up is the top reason a “missing” query is not actually missing. ACCOUNT_USAGE can lag live activity by up to 45 minutes, which rules it out for real-time incident response.Grouped Query History in Snowsight can take up to three hours to fully populate. RESULT_LIMIT in the Information Schema functions applies before any outer filter, so raise it before narrowing the search.Concurrent query durations cannot be summed to estimate warehouse runtime, since overlapping queries record the same wall-clock window independently. credits_used_cloud_services is not total per-query cost and excludes the daily cloud-services billing adjustment entirely.None of these are exotic edge cases. Every one of them shows up in a normal week of monitoring, and knowing the list in advance turns a confusing false alarm into a two-second sanity check.
Building Monitoring, Dashboards, and Alerts on Query History Querying ACCOUNT_USAGE directly for every dashboard refresh works at small scale and gets expensive fast at large scale, since it scans the full retained history on every run. A persistent fact table, loaded incrementally with query_id as the unique key and a watermark on start_time, gives dashboards a cheap, fast source to query instead.
Four dashboard views cover most monitoring needs: an executive view of cost and usage by team, a query-performance view tracking p95 latency and scan volume by hash, a reliability view of failure rates by error code, and an audit view for destructive DML and service-account activity.
A short list of alert rules catches most real incidents before someone notices manually: completed queries running past a set duration threshold, warehouse queueing above baseline, any query spilling to remote storage, and scan-volume spikes measured against a query’s own historical median rather than a fixed number.
Tools like Power BI, Tableau, or Snowsight’s own dashboarding can sit on top of this fact table, a pattern Kanerika builds regularly as part of broader business intelligence implementations.
Best Practices for Query History Monitoring at Scale Require a query tag on every production workload, set at the connection, task, or BI-tool level rather than left optional. Group by query_parameterized_hash before ranking anything by raw query text. Track percentiles, not just averages. A p95 spike hides inside a flat-looking mean far more often than teams expect. Separate interactive, batch, BI, and application workloads before setting a performance threshold, since a two-minute ETL job and a two-minute dashboard query mean very different things. Export records to owned storage before Snowflake’s retention window expires, if audit or compliance rules require longer than 365 days. Treat raw query text as restricted data. Apply least-privilege access and mask it in BI tools where the literal SQL is not the point. Most of this is a one-time setup cost. Once the tags, the role, and the fact table exist, weekly monitoring becomes a five-minute review instead of an ad hoc investigation every time someone asks why the warehouse bill moved.
How Kanerika Turns Query History Into a Governance Practice Query History sits switched on by default in every Snowflake account Kanerika inherits, yet a genuine monitoring practice around it is the exception rather than the rule. The data is there; building a real workflow on top of it is the actual work.
Kanerika’s approach follows four stages. First, assess: pull 30 to 90 days of ACCOUNT_USAGE.QUERY_HISTORY and build a baseline of top consumers by warehouse, user, and query pattern before recommending a single change. Second, design: define query-tag standards, a least-privilege monitoring role built on GOVERNANCE_VIEWER, and the dashboard views a client’s FinOps and platform teams actually need. Third, build: stand up the persistent fact table, incremental load, and alerting rules described above, tuned to the client’s real workload mix rather than a generic template. Fourth, operate: hand over a working chargeback model and a weekly review cadence so the practice survives past the engagement.
A recent example: a leading soft drink manufacturer running eight filling plants and a portfolio of proprietary brands across U.S. franchises came to Kanerika with reporting cycles that lagged the business and a Snowflake bill nobody could fully explain. Kanerika’s team rebuilt the reporting layer on governed Snowflake pipelines with proper cost visibility baked in from the start. The result: a 28% reduction in annual Snowflake spend , 45% faster refresh cycles, and 50% fewer reporting outages, achieved without slowing down the analytics the business depended on.
Case Study
28% Cost Savings with Snowflake Migration for Analytics
A leading soft drink manufacturer rebuilt its reporting layer on governed Snowflake pipelines with real cost visibility, cutting annual spend by 28% and reporting outages by 50%.
Read the Case Study → The pitfalls Kanerika’s teams watch for repeat across almost every account: query text left unmasked in BI tools that should never have shown raw SQL to end users, monitoring dashboards granted ACCOUNTADMIN instead of a scoped role, and cost dashboards that silently double-count concurrent query time because nobody accounted for warehouse-level billing. Every one of them is avoidable with the patterns covered in this guide, applied before the bill arrives rather than after.
Kanerika is a Snowflake Select Tier Partner and works across Snowflake data warehouse design, platform migrations , and ongoing cost optimization , with Query History and Account Usage as the instrumentation layer underneath all three.
Wrapping Up Query History answers more than “was it slow.” Used well, it is the record a team leans on to find expensive queries, prove who accessed what, debug a failure at 2 a.m., and build a chargeback model that survives an audit.
The teams that get the most out of it treat it as infrastructure, not a debugging tab opened once a quarter: tagged workloads, a scoped monitoring role, a persistent fact table, and a handful of alerts tuned to their own baseline rather than someone else’s defaults.
Start with the comparison table near the top of this guide, pick the right surface for the question in front of you, and build outward from there. For teams evaluating which Snowflake capabilities, including Time Travel , materialized views , or dynamic tables , actually matter for their workloads, Kanerika’s Snowflake architecture guide is a useful next stop, alongside the platform comparison in Snowflake vs. Redshift and BigQuery vs. Snowflake for teams still weighing platforms. Teams building out a full monitoring practice may also find it useful to compare notes with Kanerika’s guide to Snowflake security and external tables , both of which touch the same account-usage views covered here. Teams weighing build-versus-hire on the platform side can also see Kanerika’s take in hiring Snowflake developers , and organizations running a mixed estate may want the broader view in Databricks vs. Snowflake vs. Fabric or Microsoft Fabric vs. Snowflake . For platform-wide modernization context, Kanerika’s legacy system modernization and ETL process optimization guides round out the picture for teams planning a broader data platform overhaul, and the Snowflake Horizon Catalog guide is a natural next read for governance-focused teams. Teams newer to the platform overall may also want the grounding in Kanerika’s Snowflake alternatives comparison and the Snowflake CoWork overview for what is coming next on the platform, plus the data platform migration guide for teams planning the move itself and data analytics for the reporting layer that ultimately consumes all of this.
Frequently Asked Questions
How far back does Snowflake Query History go? It depends on the interface. Snowsight retains 14 days, INFORMATION_SCHEMA.QUERY_HISTORY() functions accept ranges within the previous 7 days, and SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY stores up to 365 days. Pick the surface based on how far back the question actually goes.
How do I see query history for all Snowflake users, not just my own? By default every user sees only their own queries. Broader visibility needs MONITOR or OPERATE on a specific warehouse for that warehouse’s queries, or ACCOUNTADMIN, IMPORTED PRIVILEGES on the SNOWFLAKE database, or the GOVERNANCE_VIEWER database role for account-wide visibility.
How do I find a Snowflake query by its query ID? Query directly against the query_id column: SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY WHERE query_id = ‘<id>’. This is the fastest and safest lookup when you already have the ID from a log, an error message, or Snowsight.
How do I find failed queries in Snowflake? Filter execution_status IN (‘FAIL’,’INCIDENT’) to catch SQL errors and platform incidents. Canceled queries need a separate check on error_message, since Snowflake does not give cancellation its own execution_status value.
Can Query History show the exact Snowflake credits a single query cost? No. credits_used_cloud_services reports only cloud-services credits tied to that statement, not warehouse compute cost, and excludes the daily cloud-services billing adjustment. Per-query cost has to be estimated by joining Query History with WAREHOUSE_METERING_HISTORY.
Does Snowflake Query History show query results? No, it stores metadata about execution, not the result set. Only the user who ran a query can view its results in Snowsight, even when another user with monitoring rights can see the query’s metadata and SQL text.
What is the difference between QUERY_HISTORY and ACCESS_HISTORY in Snowflake? QUERY_HISTORY records that a statement ran, who ran it, and how it performed. ACCESS_HISTORY records which specific tables and columns that statement actually touched, which makes it the correct source for column-level access audits.
Why is a query missing from ACCOUNT_USAGE.QUERY_HISTORY? The most common reasons are view latency of up to 45 minutes, a time filter that excludes it, insufficient privileges, or looking in the wrong account. For anything that ran in the last few minutes, check INFORMATION_SCHEMA.QUERY_HISTORY() instead.
