Explain Resource Monitors & Cost Management in Databases

55 / 66

Snowflake

Resource Monitors & Cost Management

Proactively control and cap credit spend across warehouses and the account.

Compute is billed by the second while a warehouse runs. A misconfigured task in a loop, or a query nobody cancelled, can spend a month's budget over a weekend.

A resource monitor is like a prepaid data plan with usage alerts — you get a warning at 75% of your allotment, service pauses for new usage at 100%, and everything cuts off hard past the emergency ceiling.

Key Concepts

A resource monitor is the automatic stop.

    CREATE RESOURCE MONITOR etl_cap WITH
      CREDIT_QUOTA = 1000
      FREQUENCY = MONTHLY
      START_TIMESTAMP = IMMEDIATELY
      TRIGGERS
        ON 75  PERCENT DO NOTIFY
        ON 100 PERCENT DO SUSPEND
        ON 110 PERCENT DO SUSPEND_IMMEDIATE;

The three actions differ in how brutal they are.

    NOTIFY             email only, nothing stops
    SUSPEND            running queries finish, no new ones start
    SUSPEND_IMMEDIATE  running queries are killed now

Layering them is the standard pattern: warn early, stop gracefully at the limit, and hard-stop past it as a last resort.

Scope it deliberately. A monitor can cover the whole account or specific warehouses. Account level caps total spend; per-warehouse lets the ETL warehouse have a large budget and a data science warehouse a small one, so an experiment cannot starve production.

Notifications only reach people who enabled them. A monitor emails users who have notifications turned on in their preferences, and only account administrators can receive them. A monitor that has been dutifully firing into nowhere for months is common — verify it by setting a low threshold once and checking the mail actually arrives.

It is a safety net, not a cost strategy. A resource monitor tells you that money has already been spent. The things that actually reduce the bill are elsewhere:

  - auto-suspend at 60 seconds on every warehouse
  - right-sized warehouses, checked against spilling in the query profile
  - transient tables for staging data, so no Fail-safe storage
  - Time Travel retention set per table rather than left long everywhere
  - clustering keys only where pruning has been proven to be the bottleneck

Where to look for the truth. The ACCOUNT_USAGE schema holds the history:

ACCOUNT_USAGE

    WAREHOUSE_METERING_HISTORY   credits per warehouse per hour
    QUERY_HISTORY                per query, including bytes spilled
    STORAGE_USAGE                storage, including Time Travel and Fail-safe

Joining metering history to query history is how you attribute spend to a team or a dashboard — which is what makes cost conversations concrete instead of a shared warehouse everyone blames.

One caution on suspending. A monitor that suspends a production warehouse stops the business, not just the cost. Put hard suspension on development and analytics; on production, notify and escalate.

What the interviewer is probing.1. "What can a resource monitor do?" Probing: the capability. Stalls: "Alert you." *Moves up:* notify, suspend at the end of running queries, or suspend immediately at credit thresholds, at account or warehouse level.

2. "What does a monitor not protect against?" Probing: the gap. Stalls: "Nothing." *Moves up:* storage, serverless features like Snowpipe and automatic clustering, and data transfer — they cover warehouse credits.

3. "Where do you look to find what is costing money?" Probing: the tooling. Stalls: "The bill." Moves up: WAREHOUSE_METERING_HISTORY and QUERY_HISTORY in ACCOUNT_USAGE, joined to attribute credits to queries and users.

4. "What is the first cost control to put in place?" Probing: the priority. Stalls: "Smaller warehouses." Moves up: auto-suspend on every warehouse and a monitor with a notify threshold — the common cause of a surprise bill is an idle or forgotten warehouse.