12 metrics. Every Snowflake
account. One setup.

Why monitor

• Warehouse compute is usually the single biggest line on the Snowflake bill — a spike here hits budget before finance even notices.
• Tells you exactly which workload is responsible — ETL, BI, or ad-hoc — instead of just knowing that spend is up somewhere.
• Catches runaway warehouses within the hour — a stuck query, a misconfigured auto-suspend, a bad loop — before a full day of waste piles up.

Why monitor

• Catches death-by-a-thousand-cuts spend — five services each a little over their own baseline won't trip any single alert, but together they move this number.
• One number for the whole account — rolls up warehouse compute, serverless tasks, and AI/Cortex spend so nothing slips through between individual metrics.
• The first thing worth checking each morning — a stable number means nothing needs digging into; a spike tells you exactly where to look next.

Why monitor

• Storage is billed every month forever, whether the data is useful or not — a growth spike becomes a permanent addition to the bill unless someone catches it early.
• Tells you which database is responsible before it turns into a shared, hard-to-untangle cost across teams.
• A bad pipeline can quietly add terabytes in days — by the time it shows up on the invoice, the cost is already locked in.

Why monitor

• Failsafe is mandatory and non-negotiable — you can't turn it off or shrink it after the fact, so growth here is locked-in extra cost.
• Usually signals a fixable engineering habit — a pipeline recreating large tables instead of updating them incrementally.
• Easy to miss since it doesn't show up in normal storage dashboards — often the quiet reason a storage bill runs higher than expected.

Why monitor

• Serverless tasks and Cortex AI features bill outside any warehouse — invisible until the bill arrives if nobody's watching per-service spend.
• Segmented per service so nothing gets buried — a spike in AI agent usage won't be masked by normal auto-clustering or query acceleration activity.
• AI and Copilot usage is the fastest-growing, least-visible cost category right now — this is usually the first place runaway AI spend shows up.

Why monitor

• A single runaway query can burn as many credits as hundreds of normal ones — every extra minute is warehouse capacity and money being consumed.
• Often the first sign of a regression — a schema change, a join that used to be cheap, or a workload that outgrew its warehouse.
• Users stuck waiting on a slow dashboard or pipeline rarely file a ticket right away — this catches the problem before someone complains.

Why monitor

• Queued queries mean people are waiting — dashboards load slowly and pipelines run late, with no error message, just frustration.
• Persistent queuing is a capacity signal — it's telling you to scale up or split the workload before it becomes a recurring complaint.
• Catches contention early, before an important report or exec dashboard is the one stuck behind everything else.

Why monitor

• Remote spill is 10–100× slower than in-memory processing — a spilling query burns disproportionately more credits and time for the exact same result.
• Usually means a warehouse is undersized for its workload — a clear, fixable signal instead of a vague 'things feel slow' complaint.
• Left unnoticed, this is pure waste: same output, worse performance, higher bill.

Why monitor

• A failed pipeline means stale or missing data downstream — dashboards and reports quietly go wrong with no obvious sign anything broke.
• Failure rate, not raw count, tells you when something is actually broken — versus normal background noise from a handful of ad-hoc errors.
• Pipeline breakage is usually invisible until a stakeholder notices bad numbers — by then, decisions have already been made on bad data.

Why monitor

• Tasks fail silently by default — no email, no Slack — so stale downstream data can go unnoticed for days.
• A failed nightly transform means every report built on top of it is wrong until someone happens to catch it.
• An immediate error message means you know right away whether it's a dependency issue, a schema change, or a data problem — not a scramble to diagnose from scratch.

Why monitor

• Every table nobody queries is pure cost with zero value — you're paying storage for data that isn't helping anyone.
• Some of these tables are still being ingested into daily even though nobody reads them — wasted pipeline maintenance and compute on data nobody needs.
• A prioritized cleanup list, sorted by staleness and storage size, makes it easy to cut costs and shrink the number of objects you have to maintain or worry about in an audit.

Why monitor

• Low utilization means you're paying for a warehouse that's mostly sitting idle — a clear signal to downsize or tighten auto-suspend.
• High utilization means queries are likely queueing behind each other — a capacity risk before it turns into a performance complaint.
• Turns warehouse sizing from a guess into a decision — right-size for cost without guessing at performance risk.