Snowflake Warehouses With No Resource Monitor: Find Them

To find Snowflake warehouses without a resource monitor, run SHOW WAREHOUSES and filter the resource_monitor column for the string 'null'. Then run SHOW RESOURCE MONITORS to check whether an account-level monitor exists as a backstop. A warehouse with neither has no credit limit at all, so a runaway query or a looping job can spend credits until someone notices the invoice.

This is one of the first things we check when we audit a Snowflake account. A pattern we see repeatedly in growth-stage companies is that warehouses get created one at a time: one for dbt, one for the BI tool, one for a data scientist's experiment. Nobody owns the question of what happens when one of them misbehaves. The cost surprise arrives at month end, and by then the credits are gone.

The checks below take about five minutes. You need a role that can run SHOW WAREHOUSES and read the SNOWFLAKE.ACCOUNT_USAGE schema.

How Do You Find Snowflake Warehouses Without a Resource Monitor?

Start with the warehouse list. SHOW WAREHOUSES returns a resource_monitor column. Warehouses with no monitor attached show the literal string 'null' in it, so filter on that.

SHOW WAREHOUSES;

CREATE OR REPLACE TEMPORARY TABLE tmp_unmonitored AS
SELECT "name" AS warehouse_name,
       "size" AS warehouse_size,
       "auto_suspend" AS auto_suspend_seconds,
       "owner" AS owner_role
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE COALESCE("resource_monitor", 'null') = 'null';

SELECT * FROM tmp_unmonitored;

Next, check whether an account-level monitor exists. This is your only safety net for any warehouse without its own monitor.

SHOW RESOURCE MONITORS;

SELECT "name", "level", "credit_quota", "used_credits",
       "frequency", "notify_at", "suspend_at", "suspend_immediately_at"
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));

Read the output carefully:

• If no row has level = ACCOUNT, there is no global cap.
• If a monitor exists but notify_at, suspend_at and suspend_immediately_at are all empty, it does nothing. Snowflake's own guidance is that a monitor needs at least one action defined, otherwise nothing happens when the threshold is hit.
• If a monitor exists but is not assigned to any warehouse, it sits dormant.

In our experience the dormant and action-less cases are as common as the missing ones. Someone clicked through the UI once, created a monitor, and never finished the job.

---

📺 Watch: A forgotten warehouse burned $10,000 in one weekend — Snowflake Cost Optimization

---

Which Unmonitored Warehouses Are Actually Dangerous?

Not every unmonitored warehouse deserves the same urgency. Rank them by what they have actually burned recently, and by their worst single day, not their average.

WITH daily AS (
  SELECT warehouse_name,
         DATE_TRUNC('day', start_time) AS usage_day,
         SUM(credits_used) AS credits
  FROM snowflake.account_usage.warehouse_metering_history
  WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
  GROUP BY 1, 2
)
SELECT d.warehouse_name,
       u.warehouse_size,
       ROUND(SUM(d.credits), 1) AS credits_30d,
       ROUND(AVG(d.credits), 1) AS avg_daily,
       ROUND(MAX(d.credits), 1) AS worst_day
FROM daily d
JOIN tmp_unmonitored u ON u.warehouse_name = d.warehouse_name
GROUP BY 1, 2
ORDER BY credits_30d DESC;

A large gap between avg_daily and worst_day is the signature of a warehouse that occasionally goes wrong. That is exactly the case where a monitor pays for itself. If you have already tuned auto-suspend, see our guide to finding Snowflake credits lost to idle warehouses. Idle time and missing caps are separate problems that compound each other.

Why Don't Resource Monitors Catch Everything?

This is the part that surprises people. Per Snowflake's documentation, resource monitors work for warehouses only. They cannot track spend from serverless features and AI services; Snowflake points you to budgets for those. Snowpipe, serverless tasks, automatic clustering, materialised view maintenance and search optimisation all run on Snowflake-managed compute. A monitor will neither see nor stop them.

Check how much of your consumption sits outside any monitor's reach:

SELECT service_type,
       ROUND(SUM(credits_used), 1) AS credits_30d
FROM snowflake.account_usage.metering_history
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
  AND service_type NOT LIKE 'WAREHOUSE%'
GROUP BY 1
ORDER BY credits_30d DESC;

If automatic clustering or Snowpipe tops that list, a warehouse monitor will not protect you. Budgets can notify you about those services, but Snowflake budgets only send notifications and cannot stop usage. For the clustering side specifically, we cover how to find tables burning credits on automatic clustering.

Running that diagnostic for one account is fine. Checking every dbt model in a project for the problems that cause these bills is not. Resource monitors are warehouse configuration, so fintel-scan will not see them, but it does cover the dbt project side. It is a free, open-source (MIT) CLI that runs fifteen checks locally with no warehouse connection: uvx fintel-scan

How Much Credit Quota Should You Set?

The common mistake is guessing a round number. Too low and you suspend production mid-morning. Too high and the monitor never fires. Base the quota on observed consumption, with headroom, and let the data write the DDL for you:

SELECT warehouse_name,
       ROUND(SUM(credits_used), 0) AS credits_30d,
       CEIL(SUM(credits_used) * 1.25) AS suggested_monthly_quota,
       'CREATE RESOURCE MONITOR rm_' || warehouse_name
       || ' WITH CREDIT_QUOTA = ' || CEIL(SUM(credits_used) * 1.25)
       || ' FREQUENCY = MONTHLY START_TIMESTAMP = IMMEDIATELY'
       || ' TRIGGERS ON 75 PERCENT DO NOTIFY'
       || ' ON 100 PERCENT DO SUSPEND'
       || ' ON 110 PERCENT DO SUSPEND_IMMEDIATE;' AS create_stmt
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
HAVING SUM(credits_used) > 0;

Treat the output as a first draft. Review each quota with the team that owns the warehouse, then attach it:

ALTER WAREHOUSE transform_wh SET RESOURCE_MONITOR = rm_transform_wh;

Then add one account-level monitor as the backstop. Set its quota to your total monthly budget and apply it with ALTER ACCOUNT SET RESOURCE_MONITOR. Creating monitors needs ACCOUNTADMIN unless you have granted the privilege elsewhere, which is one more reason to know who holds that role in your account.

SUSPEND or SUSPEND_IMMEDIATE: Which Should You Choose?

This is a decision about blast radius. SUSPEND lets running statements finish. SUSPEND_IMMEDIATE cancels them. Our rule of thumb:

Three gotchas we have hit in delivery:

• Polling lag. Monitors are not instantaneous; usage is checked periodically, so a runaway query can overshoot the quota before the suspend lands. Set quotas a little under what you can truly afford.
• RESUME does not override a tripped monitor. During an incident, you must raise the quota or change the monitor, not just resume the warehouse. Write this into your runbook before you need it.
• Notifications are email-only and opt-in. Account admins must have enabled notifications for them to receive anything. A monitor that notifies nobody is a monitor that fails silently.

Pair every monitor with a statement timeout. The default STATEMENT_TIMEOUT_IN_SECONDS is 172800, or two days. Lowering it on a dedicated BI warehouse caps the damage a single bad query can do:

ALTER WAREHOUSE bi_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 3600;

A real example: a Series A payments company we worked with had a single shared warehouse used by dbt, the BI tool and three analysts. A retry loop in a transformation job kept an oversized warehouse busy over a weekend. There was no monitor and no timeout, so nobody was alerted. The fix was structural, not clever: split the workloads onto separate warehouses so each could carry its own quota, then attach monitors and timeouts. Monitors can only be scoped as finely as your warehouse layout allows.

How Do You Stop Snowflake Warehouses Without a Resource Monitor Coming Back?

The gap reappears the moment someone creates a new warehouse. Three controls close it for good.

1. Make the check a scheduled job. Run the SHOW WAREHOUSES filter from the first section weekly and send any result to the data team. Treat an unmonitored warehouse the way you treat a failing test: it blocks the next release.

2. Alert on the serverless blind spot. Because monitors cannot see it, build an alert that can:

CREATE OR REPLACE ALERT serverless_credit_alert
  WAREHOUSE = alert_wh
  SCHEDULE = '60 MINUTE'
  IF (EXISTS (
    SELECT 1 FROM (
      SELECT SUM(credits_used) AS c
      FROM snowflake.account_usage.metering_history
      WHERE start_time >= DATEADD('hour', -24, CURRENT_TIMESTAMP())
        AND service_type NOT LIKE 'WAREHOUSE%'
    ) WHERE c > 50
  ))
  THEN CALL SYSTEM$SEND_EMAIL(
    'my_email_int', 'data-team@example.com',
    'Serverless credits above threshold', 'Check METERING_HISTORY');

ALTER ALERT serverless_credit_alert RESUME;

Alerts are created suspended, which is why the RESUME matters. Set the threshold from your own baseline, and remember that ACCOUNT_USAGE views lag by a few hours, so this is an early-warning system rather than a circuit breaker.

3. Restrict who can create warehouses. If every analyst can run CREATE WAREHOUSE, no monitor policy survives. Grant it to a small platform role and have new warehouses go through a pull request that includes the monitor.

On the engagements where we have put this in place, the visible change is not a smaller bill on day one. It is that cost incidents become a notification and a suspended warehouse instead of a surprise on the invoice. Finance gets a number they can plan around, and engineers stop dreading month end.

Frequently Asked Questions

Q: How do I check which Snowflake warehouses have no resource monitor?

A: Run SHOW WAREHOUSES and filter the resource_monitor column for the string 'null' using RESULT_SCAN(LAST_QUERY_ID()). Then run SHOW RESOURCE MONITORS to see whether an account-level monitor provides a backstop.

Q: Do Snowflake resource monitors cover serverless features like Snowpipe?

A: No. Resource monitors track only user-managed virtual warehouses and their associated cloud services. Snowpipe, automatic clustering, materialised view maintenance and serverless tasks need a budget or a custom alert based on METERING_HISTORY.

Q: What is the difference between SUSPEND and SUSPEND_IMMEDIATE?

A: SUSPEND stops the warehouse after running statements finish. SUSPEND_IMMEDIATE cancels in-flight queries and stops the warehouse at once. Use the gentler option on production and the harsher one on dev and ad hoc warehouses.

Q: Can a Snowflake resource monitor be set for the whole account?

A: Yes. You can assign one account-level monitor, which caps total warehouse credits across the account. Individual warehouses can also carry their own monitors, and using both is the recommended pattern.

Q: Do Snowflake budgets replace resource monitors?

A: No, they complement each other. Resource monitors can suspend warehouses but only cover warehouse compute. Budgets cover serverless and AI services as well, but they only send notifications and cannot stop spend.

Close the Gap Before the Next Invoice

The challenge for most growth-stage teams is not knowing how to write a resource monitor. It is knowing which warehouses are exposed, what the monitors cannot see, and how to keep the gap closed as the platform grows. At Fintel Analytics, we have helped fintech, payments and e-commerce teams audit their Snowflake and BigQuery estates, put cost guardrails in place and rebuild their data stacks around them. If you suspect Snowflake warehouses without a resource monitor are hiding in your account, that is a fixable problem, and finding it before the invoice arrives is far cheaper than finding it after.