None of these are sophisticated. That is the point. The expensive mistakes in a large Snowflake estate are rarely clever ones, and they persist because nothing breaks when you make them.
1. The warehouse is still on its defaults
Size, auto-suspend, cluster count, scaling policy, generation, query acceleration. Six settings, configured once at creation, usually by whoever needed a warehouse quickly, and then never revisited. Two of those defaults changed in 2026: a new standard warehouse is now Gen2 wherever Gen2 is available, and new standard warehouses start with the Query Acceleration Service switched on, which is billed separately from the warehouse whenever it is used. Adaptive Warehouses, generally available since June 2026 for Enterprise Edition accounts in selected regions, take over size, clusters, query acceleration and suspension, bill per query, and come with two defaults of their own that deserve the same check.
The default auto-suspend window, ten minutes for a warehouse created in SQL, is worth checking on every warehouse you own. A warehouse that waits that long before suspending, serving a workload that arrives in short bursts, spends a meaningful share of its billed life idle and awake. Nothing breaks. The bill simply runs higher than the work justifies. The right value depends on the workload: Snowflake recommends suspending task warehouses immediately and keeping BI warehouses up for at least ten minutes, so their cache stays warm.
Start with the warehouses nobody claims ownership of. Those are the ones most likely never to have been tuned.
2. Dashboards nobody opens are still refreshing
Dashboards accumulate. Someone builds one for a launch, a quarterly review, a customer that has since churned. The dashboard stays, its scheduled refresh stays, and the compute behind that refresh keeps being consumed on a schedule set for a question nobody is asking anymore.
This is the clearest example of waste that is invisible from inside the warehouse. The queries are legitimate. They run correctly. They are simply feeding something with no audience. Snowflake’s own insights for unused tables are unlikely to flag it, because the refresh itself reads those tables. Snowflake sees the refresh run and the BI tool sees nobody open the dashboard, so finding this cost means connecting the two.
3. Refresh frequency was set once and never matched to use
An hourly pipeline feeding a report that is read once each morning is doing twenty-three unnecessary runs a day. The schedule was probably reasonable when it was written, and then the consumption pattern changed and the schedule did not.
This is worth auditing precisely because it is boring. Nobody wants to own the job of checking whether every pipeline’s cadence still matches its readership, which is why it can go unchecked for years. Aligning refresh frequency with actual consumption is one of the few optimizations that reduces cost without any trade-off in capability. Seemore’s Frequency Optimization insight runs that check for you, flagging tables that are refreshed far more often than they are read.
4. Part of the bill is not in the warehouse
Warehouse compute is where cost reviews tend to start, because it is usually the biggest single number. But ingestion, orchestration, the BI layer and licensing all carry cost, and they are typically owned by different people with different budgets and no shared view. Even inside Snowflake, Snowpipe loading and search optimization maintenance are billed outside any warehouse. Seemore’s Inactive Users insight covers one piece of the rest, flagging Tableau and Power BI users who still hold a paid license but have not logged in for a set period.
The practical consequence is that a team can optimize a warehouse hard, report a genuine improvement, and watch total data spend stay flat because the savings were offset elsewhere. If your cost review only covers Snowflake compute, you are reviewing part of the bill.
5. Nobody owns the number
The mistake underneath the other four. When data spend is a line item finance reviews monthly and engineering sees quarterly, problems are found after they have been paid for.
Keeping costs flat while usage grows takes someone who can answer three questions on any given day: what changed, who caused it, and whether it was worth it. That is an ownership problem before it is a tooling problem, though tooling is what makes the answers available quickly enough to act on.
What to do first
Take the three warehouses with the highest uptime, not the highest cost, and find out what is keeping each of them awake. High uptime with little time spent running queries points at something keeping the warehouse awake: a scheduled job, a tool that polls it, or an auto-suspend window that is too long for the workload. High uptime that is mostly busy is usually real work, though the dashboards and schedules described above can hide there too. Snowflake’s Optimization insights in Snowsight already list warehouses that are idle more than half the time they are active, which makes a good shortlist. That check tends to surface the easiest savings available.
