In Snowflake, what does a resource monitor do when its credit quota is reached?

## The object ```sql CREATE OR REPLACE RESOURCE MONITOR analytics_rm 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; ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = analytics_rm; ``` `CREDIT_QUOTA` is the number of credits allowed per interval. `FREQUENCY` plus `START_TIMESTAMP` defines the interval and when it rolls over; `FREQUENCY = NEVER` makes the quota a lifetime cap that never resets. Triggers are percentages of the quota, each with an action. ## The three actions - **`NOTIFY`** sends a notification and changes nothing. It is the only non-destructive action and belongs at every warning threshold. Notifications go to users configured to receive them — an alert nobody receives is the classic misconfiguration. - **`SUSPEND`** stops the governed warehouses **after currently running queries complete**. In-flight work finishes; new queries cannot start. - **`SUSPEND_IMMEDIATE`** cancels running queries and stops the warehouses at once. It protects the budget at the cost of killing work, including long transforms that then have to be re-run — which can cost more credits than it saved. A sensible ladder is notify well before the limit, suspend at the limit, and suspend-immediate only slightly above it as a last resort. ## Assignment and scope A monitor is assigned either at **account** level (`ALTER ACCOUNT SET RESOURCE_MONITOR = ...`), where it watches all warehouse credit consumption in the account, or to **individual warehouses**. A given warehouse is governed by at most one warehouse-level monitor, and the account-level monitor applies on top. Creation and assignment are `ACCOUNTADMIN` operations by default, though the privileges to monitor or modify a resource monitor can be granted onward. ## What happens after suspension Suspension is not permanent. At the start of the next interval, usage resets and the warehouses become resumable. Before that, an administrator can raise `CREDIT_QUOTA` or drop/reassign the monitor to release them. This is why a monthly monitor with a hard suspend is a blunt instrument: hitting the limit on day 20 stops that team's analytics until the first of the next month unless a human intervenes. ## The two caveats interviewers probe **Enforcement is periodic, not instantaneous.** Snowflake evaluates consumption on an interval, so a large warehouse can burn some credits past the threshold before the action lands. Treat the quota as a guardrail with tolerance, not a hard financial ceiling — and do not set the quota to the exact number you can afford. **Serverless credits are outside the model.** Resource monitors govern virtual warehouse compute. Snowpipe ingestion, automatic clustering, materialized-view maintenance, search-optimization maintenance and replication run on Snowflake-managed compute and keep consuming credits regardless of monitor state. Those need separate observation through `ACCOUNT_USAGE.METERING_DAILY_HISTORY` by service type, and separate design decisions — you control them by turning the feature off or reducing base-table churn, not by capping a warehouse. ## How monitors fit a cost programme Monitors are the *stop*, not the *steering*. The useful pattern is one warehouse per team or workload so that consumption is attributable, a monitor per warehouse with notify thresholds well below the cap, and an account-level monitor as a backstop against a runaway nobody predicted. Attribution and steering come from `WAREHOUSE_METERING_HISTORY` and `QUERY_HISTORY`; the monitor exists so that a single pathological job cannot spend a quarter's budget over a weekend. ## A common mistake Setting a single account-level monitor with `SUSPEND_IMMEDIATE` at 100% and nothing else. When it fires, every warehouse in the account stops, in-flight loads are killed, and the first anyone hears of it is a production outage. Notify thresholds and per-warehouse scoping exist so that the blast radius of a budget event is one team, announced in advance.