Monitoring with ACCOUNT_USAGE

1. Monitoring with ACCOUNT_USAGE

Resource monitors are proactive guardrails. But Claro's data platform lead also needs to look back - to understand what happened, what it cost, and whether the account is running efficiently. That's what ACCOUNT_USAGE is for. This video covers what the schema is, how it differs from INFORMATION_SCHEMA, and which views answer the questions that matter most.

2. The Monitoring Problem

At the end of every month, Claro's data platform lead needs answers: which warehouses cost the most, were there runaway queries that should have been caught, is storage within budget, did any unusual login patterns occur? These questions require historical data at the account level — aggregated across all users, all warehouses, all databases. That's exactly what ACCOUNT_USAGE provides.

3. What is ACCOUNT_USAGE?

ACCOUNT_USAGE is a schema inside the SNOWFLAKE system database that Snowflake maintains for every account. It contains views that expose historical data: queries run, credits consumed, storage used, logins recorded etc. Two things to know upfront: the data has a latency of up to three hours, so it's not suitable for real-time monitoring and most views retain data for 365 days, giving you a full year of history to query against.

4. ACCOUNT_USAGE vs INFORMATION_SCHEMA

The core difference is time. INFORMATION_SCHEMA reflects the current state of your database with low latency: what tables exist, what columns they have, what privileges are in place right now. ACCOUNT_USAGE shows you the history: what happened across the account over time, including objects that have since been dropped, but with a lag of up to three hours. If you need to audit who queried a table that no longer exists, only ACCOUNT_USAGE can help.

5. WAREHOUSE_METERING_HISTORY

WAREHOUSE_METERING_HISTORY answers: which warehouses consumed the most credits? This query aggregates total credits used per warehouse over the last thirty days and ranks them by consumption. At Claro, this is how the data platform lead identifies which team's warehouse is driving the largest share of monthly spend, and whether it's running larger than the workload justifies.

6. QUERY_HISTORY

QUERY_HISTORY records every query run in the account - who ran it, on which warehouse, how long it took, and how much data it scanned. This query surfaces the ten longest-running queries from the last seven days. At Claro, this is how the platform lead finds candidates for optimization - large bytes scanned often signals missing clustering or inefficient joins.

7. STORAGE_USAGE

STORAGE_USAGE tracks how much storage the account is consuming over time - both active data storage and Fail-safe storage. The raw values are in bytes; dividing by 1024 to the power of three converts to gigabytes. At Claro, this reveals whether total storage is growing at the expected rate, and whether Fail-safe storage, the seven-day recovery buffer on permanent tables, is adding meaningful cost. Fail-safe is often overlooked but can be significant for accounts with large tables and high data churn.

8. LOGIN_HISTORY

LOGIN_HISTORY records every login attempt against the account - successful or not. Filtering for rows where error_code is not null isolates failed login attempts. At Claro, a spike in failed logins from an unfamiliar client type or outside business hours is an early signal worth investigating.

9. Let's practice!

Now it's your turn. The exercises ahead will have you querying ACCOUNT_USAGE to surface cost and usage insights from Claro's account.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.